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.
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.
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. We also established, through failed experiments, that a pure in-memory approach couldn't hold consistency guarantees at that scale — a negative result that shaped the design.”
The weak version reports a commercial outcome. The strong version states the knowledge gained — including a documented failure, which SR&ED explicitly credits.
What backs a claim like this
Each claimed element ties to a source that shows it. This is the traceability a review tests.
| Source | What it shows |
|---|---|
| GitHub commit history | The sequence of approaches tried, including the reverted in-memory prototype |
| Load-test results | Latency curves at increasing transaction counts — the non-linear degradation |
| 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 |
The takeaway
Lead with the unknown, not the feature. A reviewer is looking for what you couldn't know in advance and how you investigated it — a passing benchmark is the result, not the claim.
Draft yours from real evidence
SREDlog reads your own GitHub history, documents and records to draft a narrative like the strong one — grounded in what you actually did.
3-day free trial · No credit card required