Block Management Best Practices

In development you fetch a block, log it, and move on. Production is a different animal. You're processing every one of the ~7,200 blocks Ethereum produces per day without gaps, surviving node hiccups, and staying correct when the head reorgs out from under you. The cost of a missed block or a double-counted reorg isn't a console warning — it's drifted balances and support tickets. That's why the rigor here goes well past the happy-path code you'd write for a quick script.

The patterns below are the ones that hold up against sustained mainnet traffic: retrying failed reads without losing data, detecting reorgs by watching parentHash, processing wide block ranges without exhausting memory, and failing over to a second provider when the primary degrades. Each comes with a checklist you can lift straight into a readiness review before you point real users at https://ethereum.therpc.io/YOUR_API_KEY.

Error Handling and Recovery

Bounded retries with growing backoff. Wrap each eth_getBlock in a retry loop of 3 to 5 attempts with delays that double from a fraction of a second. Since a fresh block arrives every 12 seconds, treat a block that's still missing after a few seconds as genuinely absent rather than retrying indefinitely against an empty result.
Make timeouts non-destructive. Keep a persisted cursor of the last block number you fully committed. If a read times out, the worker can crash and restart without skipping a height — it resumes from the cursor and refetches, so a network blip never silently swallows a block.
Detect reorgs by parent hash and roll back. On each new block, compare its parentHash to the hash you stored for the previous height. If they differ, the chain reorganized: walk back to the common ancestor, undo any state derived from the orphaned blocks, then replay the new canonical ones. Never mutate finalized-block-derived state — only the unfinalized tail can move.
Configure a fallback node for continuity. A second endpoint takes over when the primary returns sustained errors or stalls. Verify the standby reports eth_chainId of 0x1 and agrees on the hash at a recent shared height before you trust its data, so failover doesn't quietly hand you a forked or lagging view.

Performance Optimization

Cache finalized blocks, expire the rest. Blocks at or below finalized are immutable — store them keyed by hash with no expiry. The unfinalized tail between finalized and latest can still change, so cap that cache to a short window (a couple of slots) sized to your reorg tolerance, not to RAM convenience.
Batch to amortize round trips. A single JSON-RPC batch covering a contiguous range replaces dozens of individual eth_getBlockByNumber calls. The win is mostly in connection and request overhead, which dominates on Ethereum's dense ranges where each block carries hundreds of transactions.
Right-size polling. When you poll the head, tie the interval to the 12-second slot and stop polling harder when the chain hasn't moved. Every poll spends Compute Units; polling faster than blocks are produced buys nothing but cost.
Stream large ranges, don't buffer them. Backfilling thousands of blocks, process in fixed batches (10 to 50) and release each batch before fetching the next. Holding a year of fully-hydrated Ethereum blocks in memory at once will OOM the worker — a bounded sliding window keeps memory flat regardless of range size.

Security Considerations

Scale your finality bar to the value. On post-Merge Ethereum the meaningful safety line isn't a raw confirmation count — it's the finalized tag, reached after roughly two epochs (~12.8 minutes), beyond which a revert would require slashing a third of staked ETH. Low-value or reversible actions can act on safe or a handful of blocks; settlement-grade flows should wait for finalized.
Check integrity before you process. Confirm each block's parentHash chains to the prior stored block, and that its number is exactly one above it. A gap or a mismatch means either a reorg or a node fault — handle it before you derive any state.
Avoid replay confusion. EIP-155 ties signed transactions to chainId 1, so a mainnet transaction can't be replayed on Sepolia and vice versa. Validate the chainId on anything you ingest, and only act on a transaction once its inclusion is confirmed by receipt at a finalized height, never from a mempool sighting.
Treat anomalies as a tripwire. Backward-moving timestamps, two providers disagreeing on the block hash at one height, an unexpected parentHash gap, or a sudden cluster of orphaned heads all point to a reorg or a misbehaving node. Pause irreversible processing and alert rather than pushing the suspect data through.

Implementation Examples

1import Web3 from 'web3';
2const web3 = new Web3('https://ethereum.therpc.io/YOUR_API_KEY');
3 
4// Robust block fetching with retries
5const fetchBlockWithRetry = async (blockNumber, maxRetries = 3) => {
6  for (let i = 0; i < maxRetries; i++) {
7    try {
8      const block = await web3.eth.getBlock(blockNumber);
9      if (block) return block;
10      throw new Error('Block not found');
11    } catch (error) {
12      if (i === maxRetries - 1) throw error;
13      await new Promise((resolve) => setTimeout(resolve, 1000 * (i + 1)));
14    }
15  }
16};
17 
18// Efficient block monitoring
19const createBlockMonitor = (callback, errorHandler) => {
20  let lastProcessedBlock = 0;
21 
22  return web3.eth
23    .subscribe('newBlockHeaders')
24    .on('data', async (blockHeader) => {
25      try {
26        if (blockHeader.number <= lastProcessedBlock) return;
27        await callback(blockHeader);
28        lastProcessedBlock = blockHeader.number;
29      } catch (error) {
30        errorHandler(error);
31      }
32    })
33    .on('error', errorHandler);
34};
35 
36// Memory-efficient block processing
37const processBlockRange = async (startBlock, endBlock, processor) => {
38  const batchSize = 10;
39  for (let i = startBlock; i <= endBlock; i += batchSize) {
40    const batch = await Promise.all(
41      Array.from(
42        { length: Math.min(batchSize, endBlock - i + 1) },
43        (_, index) => fetchBlockWithRetry(i + index)
44      )
45    );
46    await processor(batch);
47  }
48};
49 
50// Handle block reorgs
51const monitorReorgs = async (callback) => {
52  let lastBlock = await web3.eth.getBlock('latest');
53 
54  return web3.eth.subscribe('newBlockHeaders').on('data', async (block) => {
55    if (block.parentHash !== lastBlock.hash) {
56      await callback({
57        oldBlock: lastBlock,
58        newBlock: block,
59      });
60    }
61    lastBlock = block;
62  });
63};

Development Checklist

Type the block shape. Ethereum returns block fields as hex strings — number, timestamp, gasLimit, baseFeePerGas all come back as 0x-prefixed quantities. TypeScript types around your parsing layer catch the classic bug of comparing a hex string as if it were a decimal number, and document which fields exist post-Merge (an empty uncles array, sha3Uncles as the empty-list hash) versus pre-Merge.
Cover every failure branch. Error handling should account for the block being null (not yet produced), the call timing out, a 429 from rate limits, and a parentHash mismatch. Each needs a distinct response, not a single catch-all that swallows them.
Instrument from the start. Log the block number and hash on every processed block, emit a metric for head lag in seconds, and count reorgs by depth. You want this wired before launch, not bolted on during an incident.
Test the unhappy paths. Unit tests should cover a missing block, a simulated reorg where parentHash doesn't match, a batch where one read fails, and the resume-from-cursor restart. Happy-path block fetching rarely breaks; the reorg and recovery code is where regressions hide.

Production Checklist

Alert on the metrics that mean something. Head lag beyond a few slots, the latest-to-finalized gap drifting past its normal ~2-epoch span, RPC error rate, reorg depth, and processing throughput against the ~12-second block cadence. These tell you the pipeline is falling behind or the chain is misbehaving.
Wrap node calls in a circuit breaker. When a provider crosses an error threshold, trip the breaker so you stop hammering a failing node and shed load to the fallback. This keeps a single degraded upstream from cascading into your own database and queue backlog.
Run at least two providers. A single endpoint is a single point of failure. Two independent providers, both pinned to chainId 1, let you keep ingesting blocks during a regional outage or a provider's maintenance window, and let you cross-check head hashes when something looks off.
Health-check continuously. Verify the node's head timestamp tracks wall clock within a few slots, that eth_chainId returns 0x1, and that your cursor is advancing. A node can answer requests while quietly stuck — only a freshness check catches that.
Define degradation behavior in advance. When the primary slows, route to the standby; when both struggle, back off polling, widen retry budgets, and keep serving reads from finalized-block cache rather than failing user requests outright.

Common Pitfalls to Avoid

Thin error handling drops blocks silently. A single uncaught timeout that crashes a worker without a persisted cursor leaves a hole in your block history that nothing flags. The data looks complete until a balance reconciliation says otherwise.
No reorg handling corrupts state. If you commit credits or event-derived state off latest and never check parentHash, a routine head reorg leaves you having acted on a block that no longer exists on the canonical chain. On Ethereum these short reorgs are normal before finality, so this isn't an edge case — it's a matter of when.
Blind spots become outages. Without head-lag and reorg metrics, a node that fell behind or a provider serving a forked view goes unnoticed until users report wrong data. By then you're debugging in production with no signal.
Untested recovery code rots. The retry, fallback, and reorg-rollback paths run rarely, so without tests they break unnoticed and fail exactly when you need them. A pipeline that's never exercised its failure branches is fragile by construction.