Sub-second reconciliation at 10M+ transactions
Northwind's accounting platform had to reconcile ledgers in under a second for accounts with tens of millions of transactions. Their existing batch approach took minutes and the standard database techniques couldn't close the gap. The example concerns that reconciliation investigation; customer-interface work, ordinary deployment and unrelated product features are outside its scope.
Technological uncertainty (T661 line 242)
“We needed to make our reconciliation feature faster because customers complained it was slow.”
“It was uncertain whether sub-second reconciliation was achievable for accounts exceeding 10 million transactions. Established indexing and incremental-diff techniques degraded non-linearly past ~2 million rows, and it was unknown whether any data structure could hold the invariants while meeting the latency bound.”
The weak version describes a business goal and effort. The strong version names the specific technological unknown and why the known methods couldn't be assumed to work.
Work performed (T661 line 244)
“We tried several optimizations, rewrote the reconciliation engine and tested it until it was fast enough.”
“We compared established indexing and incremental-diff approaches as ledger size increased, recording latency and reconciliation consistency under the same workload. Their degradation led us to test an in-memory prototype. That prototype failed the consistency checks, so we rejected it and tested partitioned delta-tree variants with lazy invariant checking. We compared each variant with the baseline and retained the failed runs alongside the final measurements.”
The stronger version connects each approach to the observation that changed the next experiment. A real narrative would need the actual workload, run records and results behind this sequence; a list of optimizations would not supply them.
Technological advancement (T661 line 246)
“We successfully built a faster reconciliation engine that our customers are happy with.”
“We advanced our understanding of incremental reconciliation under high cardinality: a partitioned delta-tree with lazy invariant checking held sub-second latency to 12M transactions in testing. Failed experiments also showed that a pure in-memory approach could not hold consistency guarantees at that scale, which shaped the design.”
The weak version reports a commercial outcome. The strong version states the knowledge gained and includes a documented failure.
What could support a claim like this
The matrix pairs each described element with the kind of source that could support it. The actual records still need review.
| Source | What it shows |
|---|---|
| GitHub commit history | The sequence of approaches tried, including the reverted in-memory prototype |
| Load-test results and workload definition | The transaction counts, workload, test conditions and latency measurements needed to compare the baseline with each experimental variant |
| Design docs / ADRs | The hypotheses and why standard approaches were expected to fail |
| Tickets | The framing of the problem as a technical unknown, dated during the work |
| Consistency checks and failed-run records | Why the in-memory prototype was rejected, including whether a faster result still preserved reconciliation invariants |
| Time entries with an allocation explanation | Who performed the investigation and how its hours were separated from interface changes, deployment and other product work; commits alone do not establish hours |
The takeaway
Lead with the unknown rather than the feature. A reviewer is looking for what you could not know in advance and how you investigated it. A passing benchmark is the result, not the claim. If the workload definition or failed consistency checks are missing, identify that evidence gap instead of supplying a plausible explanation. These excerpts illustrate the structure of a narrative, not a complete project description or an eligibility conclusion.
Draft yours from real evidence
Use approved GitHub activity, uploaded documents and project records to prepare an editable narrative draft for review.
7-day free trial · No credit card required