How do chain reorganizations affect a dApp or backend service, and how do you handle them?

What the interviewer wants to hear

• Recent blocks can be replaced, removing or reordering transactions
• Use confirmation depth or safe and finalized block tags depending on value
• Indexers track block hashes and roll back orphaned data
• Idempotent processing keyed by tx hash and log index
• Different chains and L2s have different finality rules

Model answer

A reorg happens when the network switches to a different chain tip, so transactions in the replaced blocks can vanish or move. On Ethereum, reorgs beyond one or two blocks are rare, but finality takes about 13 minutes, and other chains differ. For low-value UI updates I show results after one confirmation. For anything involving money, like crediting deposits, I wait for the safe or finalized block tag, or a confirmation depth suited to the chain. My indexers store each block's hash and parent hash, detect when they no longer match, and roll back events from orphaned blocks before reprocessing. Processing is idempotent, keyed by transaction hash and log index, so replays do not double-count. On L2s I also separate soft confirmation from the sequencer and real finality on L1.

More medium Blockchain Developer questions

• What is a reentrancy attack and how do you prevent it?
• What techniques do you use to reduce gas costs in Solidity contracts?
• How do you test a smart contract before deploying it to mainnet?
• How do upgradeable smart contracts work, and what are the trade-offs?
• What is a blockchain oracle and how do you use price data safely?
• How do signature-based approvals like ERC-2612 permit and Permit2 work, and what are their risks?
• How do you build a reliable dApp frontend that reads and writes contracts with viem and wagmi?
• How do you design admin control for a protocol so it can be maintained without making users trust a single person?
• Walk me through how you deploy a set of contracts to mainnet safely.