Skip to content
Nythas Data Systems

Selected work

Systems we rebuilt while they stayed in production

4 representative engagements. Clients are described by sector rather than named; we publish outcomes, not logos, unless a reference is explicitly cleared.

Engagements

CS-001

SERIES-C FINTECH

MONTHLY COMPUTE SPEND
-61%
P95 QUERY SPEEDUP
3.4x
SLA BREACHES DURING MIGRATION
0

Cutting warehouse spend 61% without touching the SLA

Challenge
Warehouse costs had grown 4x in eighteen months while query latency got worse. Nobody could attribute spend to a team, so nobody could cut it.
Approach
We instrumented query-level attribution, rebuilt the worst offenders as incremental models, and introduced tiered storage with automatic suspension on idle warehouses.
What changed

Before

  1. dbt models 340 models
  2. Full refresh every run
    Always-on warehouse never suspended
  3. Untagged queries
    One line item no owner

After

  1. dbt models incremental
  2. Changed rows only
    Tiered + auto-suspend idle in 60s
  3. Tagged queries attributed
    Spend per team query-level

The SLA was the constraint, not the target. Nothing below was allowed to slow down while this was happening.

  • SNOWFLAKE
  • DBT
  • AIRFLOW
Discuss a system like this
CS-002

GLOBAL LOGISTICS

END-TO-END EVENT LATENCY
<800ms
PEAK SUSTAINED EVENTS
12M/s
PARALLEL-RUN BEFORE CUTOVER
6 wks

From nightly batch to sub-second event streaming

Challenge
Fleet telemetry landed in a nightly batch, so operations were always reacting to yesterday. Peak-season backfills routinely ran past the next morning.
Approach
We introduced a Kafka backbone with Flink stateful processing, kept the legacy batch path running in parallel for six weeks, and cut over per-region behind flags.
What changed

Before

  1. Fleet telemetry
  2. Nightly batch 6h 40m
    Warehouse stale by a day
  3. Next morning
    Operations reacting to yesterday

After

  1. Fleet telemetry
  2. Append
    Kafka 12M events/s
  3. Windowed joins
    Flink stateful
  4. End to end <800ms
    Operations live

The batch path above kept running beside this one for six weeks. Cutover was per-region, behind a flag, and reversible until the last region was done.

  • KAFKA
  • FLINK
  • KUBERNETES
Discuss a system like this
CS-003

HEALTHCARE PLATFORM

ENGINEER-HOURS PER AUDIT
-88%
COLUMNS CLASSIFIED & COVERED
100%
MANUAL EVIDENCE COLLECTION
Zero

SOC2 evidence generated by the pipeline, not by hand

Challenge
Audit prep consumed a quarter of the platform team every cycle. PII masking was applied inconsistently and lineage was reconstructed manually from tribal memory.
Approach
We pushed policy into the transformation layer, column-level classification, automated masking, and lineage emitted as a build artefact that satisfies the auditor directly.
What changed

Before

  1. Transformations policy applied by hand
  2. Inconsistent masking
    Warehouse
  3. Lineage from memory each cycle
    Audit evidence a quarter of the team

After

  1. Transformations policy as code
  2. Masking at build column-level
    Warehouse 100% classified
  3. Lineage artefact every build
    Auditor reads the artefact

Evidence is a build output here, so it cannot drift from the pipeline that produced it. If the build passes, the evidence is current.

CS-004

ML-NATIVE SAAS

TRAIN/SERVE SKEW
<0.5%
MEDIAN MODEL TIME-TO-PROD
9 days
EXPERIMENT THROUGHPUT
4x

A feature store that models and services agree on

Challenge
Training and serving used two separate feature paths. Offline metrics never matched production, and every model rollback became a forensic investigation.
Approach
One declarative feature definition compiled to both offline and online paths, with automated skew detection wired into CI so drift fails the build.
What changed

Before

  1. Two definitions training and serving
  2. Written twice
    Two feature paths drift unmeasured
  3. Offline never matched online
    Production rollback = investigation

After

  1. One definition declarative
  2. Compiled to both
    Offline + online compiled from it
  3. Skew check in CI drift fails the build
    Production skew <0.5%

The check runs in CI rather than on a dashboard, because a drift number nobody is paged for is a number nobody reads.

  • MLFLOW
  • PYTORCH
  • KUBERNETES
Discuss a system like this

Tell us what's breaking.

You get a lead architect on the call, not a salesperson. If we are not the right fit we will say so and point you somewhere better.