Talk →
Case · UniWhales

Three workstreams in parallel, no downtime, 40% more transaction capacity.

Blockchain analytics platform running hot under load. Arc10 staffed three senior engineers in parallel — Kubernetes scaling on accurate signals, an Apache Airflow ETL rebuild with progressive cutover, and a test suite that catches what production used to find. Six months, completed.

Engagement
SectorBlockchain analytics
StatusCompleted
Engagement6 months
TeamThree senior engineers, in parallel
TechKubernetes · HPA · Prometheus · Grafana · Apache Airflow · Python · IaC
§ 01
The situation

Volume was the business. Volume had outgrown the team.

UniWhales is a blockchain analytics platform. The product processes Ethereum transaction data at volume, surfacing patterns that institutional and retail traders pay to see. Volume was not the problem; volume was the business. The problem was that volume had outgrown the engineering team.

Three things were happening at the same time. The Kubernetes setup was running hot under load — autoscaling thresholds were tuned for last year's traffic, and the cluster was either over-provisioned and bleeding cost or under-provisioned and dropping requests. The ETL pipeline that ingested transaction data was a backlog away from missing the SLAs the product made to customers. And the test automation was not catching the failure modes that mattered most — regressions were being found in production, by users, instead of in CI.

Three workstreams. One small in-house engineering team. UniWhales did not need a contractor on one of them. They needed all three taken on at once, in parallel, by senior engineers who could own the outcome instead of waiting for direction.

§ 02
The approach

Three workstreams, in the right order.

Arc10 staffed three workstreams in parallel — one senior engineer per track, plus shared accountability across the bench. The engineers joined UniWhales' Slack on day one, attended their standups in real time, ran on their sprint cadence, and reviewed each other's PRs alongside the in-house team.

01

Sequencing was the decision that mattered most

The instinct was to fix the Kubernetes scaling first, because the cost pain was loudest. The right answer was to start with the ETL pipeline — because the test automation work depended on having a stable pipeline to test against, and the Kubernetes work needed accurate load metrics that the new pipeline would produce.

02

ETL first, then tests, then Kubernetes

Sequencing the workstreams in that order made each subsequent piece cheaper. The ETL rebuild produced the signals; the test suite hardened the rebuild; the Kubernetes work then scaled on top of a pipeline whose load characteristics were known and whose failure modes were caught upstream.

03

Embedded, not external

Arc10's engineers operated as part of UniWhales' team — Slack, standups, sprint cadence, code review. Three parallel tracks under one shared accountability. The model that produces work the in-house team can own afterward, instead of a hand-off that breaks at the seams.

The work that mattered most on this engagement was not any one of the three workstreams in isolation. It was running them in parallel, in the right order, without dropping the live product on the floor.

Three senior engineers, one per workstream — Kubernetes / SRE, data engineering / Airflow, test infrastructure — with shared review and integration across the tracks. End to end, six months.

§ 03
What we built

Three tracks, one team.

01

ETL pipeline rebuild

The transaction ingestion pipeline moved onto Apache Airflow. Python DAGs replaced the previous ad-hoc job-scheduler approach, with explicit retry semantics, idempotent task design, and observability on every stage. The rebuild went in alongside the existing pipeline and traffic was cut over progressively — no big-bang switch, no downtime. The new pipeline was double-running until the new path was validated against the old one in production.

02

Kubernetes scaling, properly

Horizontal Pod Autoscalers tied to custom metrics — not just CPU. The cluster scales on the signals that actually predict load (queue depth, in-flight transactions, downstream latency), monitored on Prometheus and Grafana. Infrastructure-as-code rollouts mean the cluster can be reproduced, rolled back, and reasoned about. The over-provisioning bleed stopped; the under-provisioning drops stopped.

03

Test automation that catches what matters

Test coverage went in alongside the new pipeline so the rebuild did not regress quietly. The suite catches the categories of failure UniWhales was previously finding in production — data-shape regressions, partial-write states, retry-loop infinite cases — not just unit-level happy paths. CI gates on the suite; production stops being where bugs are first seen.

§ 04
Outcomes

Faster, cheaper, caught upstream.

Production figures
Capacity+40%
Transaction processing capacity against the same infrastructure spend
MigrationZero
Downtime through cutover · pipelines double-ran until validated
Engagement6 mo
Three senior engineers, three parallel workstreams, completed
  • 40% more transaction processing capacity against the same infrastructure spend, post-rebuild — the load-bearing number for the engagement.
  • No downtime through the migration. Cutover ran progressively; the new pipeline double-ran with the old until parity was validated in production.
  • Regression rate against the test suite dropped — bugs that previously surfaced in production are now caught in CI before they ship.
  • Cost-to-serve improved because the cluster auto-scales on accurate signals instead of running over-provisioned for safety.
Engagement footnote

Three workstreams, six months, no downtime. The kind of engagement that looks like one team because it ran like one team.

Back to the work
StatusCompleted
Engagement6 months
WorkstreamThree parallel tracks, Arc10-led
CadenceEmbedded in UniWhales' Slack, standups, and sprint cadence throughout
Talk

Talk to a senior engineer.

Want to walk through the Kubernetes architecture, the Airflow DAG design, or the cutover plan? The senior engineer who built it will take the call.

What to expect
Emailhello@arc10.io
First replyWithin one business day
First call30 minutes with a senior engineer
No salesEngineering questions, engineering answers