Blockchain Infrastructure: Nodes, RPC, Indexers & Monitoring Setup

We see it all the time: smart contracts are written, audits passed, but the project stumbles on basic infrastructure—nodes crash, RPC rate limits throttle, events go missing. That's why we build infrastructure so you don't have to think about it. Production-ready blockchain infrastructure isn't just a node; it's a full stack: node setup, RPC multiplexing, custom indexer, event pipeline, and monitoring. Our blockchain infrastructure includes dedicated nodes, failover RPC, custom indexers, and monitoring—all in one package.

With over 5 years of experience and 20+ blockchain projects, we ensure production-ready infrastructure that cuts incident time by 80%. For a typical DeFi project, our infrastructure saves $24,000/year in RPC fees. For a project handling 100 million monthly requests, self-hosted nodes reduce RPC costs from $60,000 to $12,000 annually—a savings of $48,000.

In 3–6 weeks we set up everything from scratch: from stack selection to a documented runbook with alerts. Experience shows that a well-designed infrastructure cuts incident time by 80%.

Production-ready infrastructure includes dedicated nodes with failover, custom event indexers, monitoring of all metrics, and automated recovery. Without it, even a perfect smart contract remains inaccessible to users. We configure each layer: from choosing the node client (Reth or Geth) to Prometheus alert configuration. Let's break down the key components using a real DeFi project handling 1000 requests per second.

Layers of Blockchain Infrastructure

+-------------------------------------------------+ | Application Layer | | (Frontend, API, Business Logic) | +-------------------------------------------------+ | Data Access Layer | | (GraphQL API, REST API, WebSocket) | +-------------------------------------------------+ | Indexing Layer | | (The Graph / custom indexer / event processor)| +-------------------------------------------------+ | Node Layer | | (Archive node / full node / light client) | +-------------------------------------------------+ | Blockchain Layer | | (Ethereum / L2 / custom chain) | +-------------------------------------------------+ 

Each layer has reliability and scaling requirements. We'll cover the key ones.

Self-Hosted Node vs RPC Provider: Selection Criteria

Self-hosted nodes are needed when: you require archive nodes for historical queries (providers charge a lot); rate limits are critical (100k+ requests/day makes providers either expensive or restrictive); privacy matters (provider sees all requests); debug/trace methods are needed (not available from providers).

For 80% of projects, an external provider suffices. Self-hosted nodes are for when load or control requirements exceed limits.

Running Reth (Rust Ethereum) syncs faster than Geth—full node sync in 24–48 hours. Example config:

reth node \ --chain mainnet \ --http \ --http.addr 0.0.0.0 \ --http.port 8545 \ --http.api eth,net,web3,debug,trace \ --ws \ --ws.addr 0.0.0.0 \ --ws.port 8546 \ --authrpc.addr 127.0.0.1 \ --authrpc.port 8551 \ --authrpc.jwtsecret /path/to/jwt.hex \ --datadir /data/reth 

Hardware requirements: 4+ CPU, 16+ GB RAM, 2+ TB NVMe, 25 Mbps link. Even with a provider, failover is needed. Pattern: load balancer with health checks:

class RpcMultiplexer { private providers: JsonRpcProvider[]; private healthStatus: Map<string, boolean>; constructor(endpoints: string[]) { this.providers = endpoints.map(url => new JsonRpcProvider(url)); this.healthStatus = new Map(); this.startHealthChecks(); } async getHealthyProvider(): Promise<JsonRpcProvider> { const healthy = this.providers.filter( (p, i) => this.healthStatus.get(String(i)) !== false ); if (healthy.length === 0) throw new Error('No healthy RPC providers'); return healthy[Math.floor(Math.random() * healthy.length)]; } private startHealthChecks(): void { setInterval(async () => { for (let i = 0; i < this.providers.length; i++) { try { await this.providers[i].getBlockNumber(); this.healthStatus.set(String(i), true); } catch { this.healthStatus.set(String(i), false); } } }, 15_000); } } 

Event Pipeline: Components and Necessity

The pipeline processes blockchain events: listens to new blocks, parses logs, stores data, and notifies services. The Graph is a ready solution for most EVM projects. For complex logic, we write a custom indexer.

A custom indexer is built in TypeScript with cursor resumption and transactional processing. Example:

class EventIndexer { private db: Pool; private provider: JsonRpcProvider; async indexFromBlock(startBlock: number): Promise<void> { let currentBlock = startBlock; const headBlock = await this.provider.getBlockNumber(); while (currentBlock <= headBlock) { const batch = Math.min(currentBlock + 999, headBlock); const logs = await this.provider.getLogs({ fromBlock: currentBlock, toBlock: batch, address: CONTRACT_ADDRESSES, }); await this.db.query('BEGIN'); try { for (const log of logs) await this.processLog(log); await this.updateCursor(batch); await this.db.query('COMMIT'); } catch (e) { await this.db.query('ROLLBACK'); throw e; } currentBlock = batch + 1; } } } 

Key principles: cursor resumption, idempotency, reorg handling.

For high-load systems, we use Kafka as a bus: listeners write to topics, processors read and persist to PostgreSQL. This provides horizontal scaling and fault tolerance.

Why Monitoring is Critical for Blockchain Infrastructure?

Our stack: Prometheus + Grafana. Metrics: indexer lag (indexer_lag_blocks), total events processed (events_processed_total), RPC errors (rpc_errors_total with method and error_type labels), block processing time (block_processing_seconds). Alerts: lag > 100 blocks → critical, rpc errors > 10/min → warning, processing > 30s → warning.

resource "aws_instance" "node" { ami = data.aws_ami.ubuntu.id instance_type = "c6i.4xlarge" root_block_device { volume_type = "gp3" volume_size = 2000 iops = 3000 } user_data = templatefile("${path.module}/scripts/node-init.sh", { chain = "mainnet" }) }