Design Blockchain Indexer

Problem Statement: Turning Chain Data into Queryable Facts

A blockchain indexer turns the chain's append-only, hard-to-query event log into fast, structured, queryable facts — "every USDC transfer to this address," "this pool's 30-day volume" — questions a raw node answers slowly or not at all. It ingests canonical blocks, decodes contract events against their ABIs, and serves low-latency REST/GraphQL/SQL. This is the pattern behind The Graph (subgraphs), Dune (SQL analytics), and Alchemy/Covalent (enhanced APIs).

The crucial framing: an indexer is a read-optimized projection of the chain, not a validator — it does not re-run consensus, it trusts canonical blocks from nodes and transforms them into query-friendly tables. Its correctness job is narrower but sharp: index exactly what happened on the canonical chain, and correct itself when the chain reorganizes.

The scale to anchor: ~7,200 blocks/day (Ethereum, ~12s blocks), ~50M logs/day to decode and store, and ~100k query QPS at peak on the serving side. The defining consistency model: a strongly-consistent writer (the ingest path commits canonical data exactly once) feeding eventually-consistent read replicas behind a cache — plus a safe_height that lags the chain tip by ≤5 blocks so queries never serve data a reorg might erase.

The failure stories that define this domain — and what an interviewer probes — are specific: a deep reorg that must rewind and re-apply already-indexed blocks, RPC provider divergence (two nodes disagree on a block) triggering a quorum halt, an ABI mismatch routing undecodable logs to a dead-letter queue, and replica lag forcing read-routing to flip. These, not a generic ETL diagram, are the substance.