SIMULATED

Data Pipeline Visualizer

Source → change capture → broker → raw → transform → warehouse → dashboard. Turn on a fault and read two things: the number the dashboard reports, and the number that is actually true. The gap between them is the whole subject of this domain.

SIMULATEDEverything numeric on this page

Every value below comes from a model in this repository — src/de/sim/pipeline.ts — run over a deterministic set of generated orders. Nothing was measured on a real platform, and a real platform would not give you these figures anyway. There are no prices, because a price would belong to somebody else's contract. What transfers is the shape: which stage loses the rows, and which check would have noticed.

The invariant that makes this a model rather than a prop: with no faults on, reported equals truth exactly. Every divergence you see afterwards is attributable to something you turned on. That is not how production feels, and it is exactly why this is worth doing first — you get to learn the signatures while you still know the answer.

The second thing to watch is the check row. No two faults here fail the same set of checks. That is not a convenience of the model; it is the reason diagnosis is possible at all, and it is what a real platform is trying to buy when it invests in tests rather than in alerting on task status.

The lab

Toggle faults on the left, mitigations underneath, and read the dashboard number against the truth.

Data pipeline visualizer
Data pipeline visualizer
Toggle a fault and watch it travel. The stage table localises a loss to an arrow rather than to a system; the checks say which signal would have fired; the two revenue figures say whether anybody would have looked.
faults
mitigations
true revenue
934,498.90 minor unitssim
dashboard shows
1,010,654.50 minor unitssim
published
yes
freshness lag
12 minsim
The dashboard is off by 76,155.60 minor unitssim — overstated. 1 of 6 checks fire, so somebody would have found out from a monitor rather than from a person.
stages — what one row means, and how many there are
StageOne row isRows inRows outΔ
Source database
One order, in its current state.4,000
4,000
Change capture
One committed change to one order.4,000
4,000
Event log
One delivered change record — possibly delivered more than once.4,000
4,000
Raw landing
One line in an immutable file, exactly as received.4,000
4,000
Transformation
One order, deduplicated and windowed.4,000
4,000
Serving table
One order, with measures and dimension keys.4,000
4,000
Dashboard
One number, with the grain now invisible.4,000
1
aggregated

Row counts are simulatedsim. The last row is where the grain disappears: one number, with nothing on the screen recording what one row of the source meant.

checks — and what each one is blind to
CheckResultWhat the model foundStill misses
Completeness
Every order the source recorded for the period reached the serving table.
passEvery order in the source for this period is present.Duplicates that coincidentally offset losses, and any period that is not yet closed.
Uniqueness
Each order id appears exactly once in the serving table.
passEvery order id appears exactly once.A genuine duplicate that arrived under a new key — a producer retry with a fresh event id looks like a second order.
Freshness
The newest complete record is recent enough for the decisions this table drives.
passNewest complete record is 12 simulated minutes old.Data that is perfectly fresh and completely wrong. It also fires falsely on a period where the source genuinely produced nothing.
Validity
Every amount is non-null and parses as a number.
passEvery amount is non-null and numeric.A value that is well-typed and wrong — a price in the wrong currency passes every type check there is.
Distribution
The shape of the day resembles the days before it, per country and in total.
passLargest per-country share drift 0.8pp; total volume drift 0.0%.Slow drift, and any error that preserves the shape while changing every value inside it.
Reconciliation
Revenue summed in the serving table equals revenue summed in the source for the same closed period.
FAILServing table reports 1,010,654.50 against a source total of 934,498.90.Anything wrong identically at both ends — a bug in logic shared by the extract and the model reconciles perfectly.
consequences, in the order they occur
  • 1Refunded orders were counted at their full value. Every row is present, unique, fresh and well-typed — and revenue is overstated.
partition load · straggler 2.34×sim the mean
US1,171 rows
DE678 rows
GB507 rows
FR437 rows
PL364 rows
ES350 rows
IT262 rows
NL231 rows
Fail the transform logicreconciliation movestry: Fix the transform logic

The revenue model stops subtracting refunds.

The code does exactly what it was told, and what it was told is wrong. Every row is present, unique, fresh, well-typed and normally distributed — and the number is too high.

SIMULATEDRow counts, revenue and check results all come from the row-level model in src/de/sim/pipeline.ts. Amounts are minor units in a model with no currency.

The eight faults, and where each one is taught properly

Open one to see what is really happening underneath the symptom, and which signal separates it from the others.

Where to go next

Each fault above has a page of its own where it is the whole subject.