Indexers & Distributed Systems
The path a transaction takes from client to consensus and back, and the indexer that makes it queryable. Cursors, replay, idempotency and the failure modes that only appear at scale.
// lessons
- 01
The Indexer Pipeline and a Cursor That Survives Restart
Build the four-stage pipeline — ledger source, cursor, processor, store — and restart it mid-stream without losing or repeating work.
- 02
Commit the Cursor After the Effect, Never Before
Inject a crash between the two writes and measure both orderings: cursor-first silently loses an event, effect-first duplicates one — and only one of those is recoverable.
- 03
Idempotency Under At-Least-Once Delivery
Process a stream that duplicates and reorders events, twice over, and land on exactly the state a perfect exactly-once feed would have produced.
- 04
Surviving a Reorg: Roll Back to the Fork, Reapply the Branch
Detect that an incoming block forks below your head, unwind the orphaned blocks in reverse height order, and reapply the winning branch.
- 05
Transaction Status as a State Machine That Rejects
Encode Received/Validating/Submitted/Pending/Confirmed/Failed as a transition table whose default arm refuses illegal moves and leaves the state untouched.
- 06
Quorum Arithmetic: R + W > N, and What a Partition Does to It
Compute which (N, R, W) configurations guarantee a read sees the last write, then run a 3|2 partition and watch the minority side refuse both reads and writes.
- 07
Ordering Events Without a Clock: Lamport and Vector Stamps
Stamp a distributed event trace with both clock types and show the pair where Lamport reports an order that causality does not support.
Every exercise compiles and runs in the Forge sandbox — standard library only, no external crates.
