A 20-person engineering team should stop treating blockchain infrastructure as a platform to own. In the last two years, managed RPC, rollups, account abstraction, and indexers changed the trade-off. My position: most small engineering organisations should rent the chain edge, keep business state off-chain, and put only the narrowest settlement or audit surface on-chain.
Owning nodes became a worse default because the chain edge got more specialized
The old advice was simple: run your own Ethereum node, avoid vendor dependency, and you will be more reliable. That advice is now outdated for a 15-30 person engineering organisation because node operation has become a specialised reliability discipline while managed providers have improved the parts most product teams actually need: low-latency JSON-RPC, archive access, simulation, webhooks, and multi-region failover.
The post Blockchain Infrastructure for Scalable IT Systems is useful as a checklist, but I would not copy its ownership bias, because a small team usually gains more reliability from fewer components than from running nodes it cannot patch, monitor, and recover at 03:00.
What changed is not that self-hosting became impossible. Erigon, Reth, Geth, Nethermind, Lighthouse, Prysm, and Teku are all serious software. The change is that the operational boundary moved. Since Dencun activated on Ethereum mainnet in March 2024, rollup traffic patterns, blob fee markets, and provider APIs have mattered more to application teams than raw node possession. EIP-4844 has a protocol-set target of 3 blobs per block and a maximum of 6, which changed L2 cost dynamics because data availability became a separate market rather than ordinary calldata competition.
I would not run a production Ethereum archive node as the default for a product team of this size, because the staff cost and incident surface exceed the practical benefit unless your product depends on deterministic historical replay. If you truly need self-hosting, use Reth 1.x or Erigon 2.x with documented pruning choices, pin client versions, and test upgrades on Sepolia or Holesky before mainnet. If you do not need that, use Alchemy, Infura, QuickNode, Ankr, or AWS Managed Blockchain Access and spend your engineering attention on idempotency, retries, and data reconciliation.
The outdated slogan is “own the node to own the reliability.” The current version should be “own the failure model,” because your users do not care whether an outage came from Geth compaction, a provider 429, a stuck indexer, or a bad nonce manager.
BaaS stopped being a toy, but vendor exit became the real architecture
Two years ago, many tech leads treated Blockchain as a Service as a prototype convenience. That stance is now stale because providers moved beyond hosted RPC into transaction simulation, private mempool routing, gas sponsorship, policy engines, NFT APIs, traces, and alerting. The guide Blockchain as a Service: What IT Leaders Should Know in 2025 should be read with a sharper vendor-exit lens, because the product risk has shifted from “can the vendor run nodes?” to “can we leave without rewriting our application?”
For a small engineering organisation, the right BaaS posture is boring: wrap every provider behind your own interface, store canonical transaction intent in PostgreSQL 16, emit traces through OpenTelemetry 1.27, and alert on Prometheus counters before the provider’s dashboard tells you something is wrong. This is less glamorous than “decentralized infrastructure,” but it is safer because your app can degrade instead of freezing when one provider changes a quota or an API response shape.
Use JSON-RPC as the lowest common denominator where possible. Avoid wiring product logic directly to an Alchemy-specific enhanced API, a QuickNode add-on, or a Tenderly simulation response unless the feature is explicitly isolated behind an adapter. Ethers.js v6 and viem 2.x both work well for this boundary; I prefer viem for newer TypeScript services because its transport and chain configuration are more explicit, while Ethers.js v6 still wins when your team already has battle-tested utilities around it.
A practical minimum health check should run outside the vendor dashboard, because a dashboard can be green while your credentials, region, or method mix is broken. Save this as rpc-check.mjs and run it with Node.js 20:
const rpc = process.env.RPC_URL || "https://cloudflare-eth.com";
const started = performance.now();
const res = await fetch(rpc, {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_blockNumber", params: [] })
});
const json = await res.json();
const block = parseInt(json.result, 16);
console.log(`block=${block} status=${res.status} ms=${Math.round(performance.now() - started)}`);
if (!Number.isFinite(block)) process.exit(1);
Set an operator-chosen starting SLO of 800 ms p95 for simple methods such as eth_blockNumber and eth_call, then tune it after one week of traffic because wallet flows feel broken long before a backend is technically down. Track eth_sendRawTransaction separately because mempool acceptance is not comparable to read latency.
“Chain agnostic” is now mostly marketing because finality, fees, and wallets leak into the product
The older recommendation to stay chain agnostic sounds prudent, but it is often false economy because finality assumptions, bridge delays, account models, and wallet support leak into your user experience. Ethereum mainnet, Base, Arbitrum One, Optimism, Polygon PoS, and Solana do not behave like interchangeable databases, and pretending they do creates hidden product bugs.
A better default is to be provider portable and chain deliberate. Provider portability means your service can switch from Infura to Alchemy or from QuickNode to Ankr. Chain deliberateness means you pick a settlement environment because its constraints match the product. If your user flow needs low fees and EVM tooling, Base or another OP Stack chain may win because Solidity 0.8.24, Foundry, Hardhat 2.22, OpenZeppelin Contracts 5.x, Safe smart accounts, and WalletConnect v2 are familiar. If your system needs Ethereum L1 settlement credibility, mainnet may win because the security assumptions are simpler to explain, even though fees and latency are worse.
The numbers matter here. Ethereum finality is built around epochs of 32 slots, a protocol-defined unit that matters when you decide whether to show a transaction as reversible, pending, or settled. For L2 withdrawals to L1, a 7-day challenge period on optimistic rollups is a published design constraint in common OP Stack and Arbitrum-style flows, so a “withdraw now” button may need product copy, support tooling, and reconciliation jobs. A tunable starting limit of 10,000 blocks for eth_getLogs windows keeps indexer backfills less likely to timeout, although your provider and contract event density should decide the final value.
The advice I would retire is “abstract the chain behind a generic repository and decide later.” I would retire it because the abstraction usually collapses at gas estimation, confirmations, signatures, reorg handling, token standards, and wallet UX. ERC-20 transfers, ERC-721 ownership checks, EIP-712 signatures, EIP-4337 user operations, and Solana transaction messages are not the same shape, and your domain model should admit that early.
The real comparison is managed RPC versus self-hosted clients, not decentralization versus convenience
Here is the explicit comparison a tech lead should put in the design doc.
- Option 1: self-hosted execution and consensus clients, such as Reth plus Lighthouse or Erigon plus Teku. This wins when you need deterministic trace replay, sensitive read privacy, custom indexing near the node, or very high stable query volume, because you control the data path and can tune storage, pruning, and locality. It costs multiple terabytes of NVMe planning headroom, client upgrade work, chain incident monitoring, backup strategy, and a real on-call rotation; a practical planning number is 4 TB of fast storage per mainnet node before you add replicas or archive ambitions, and that number should be validated against your exact client mode.
- Option 2: managed RPC and BaaS, such as Alchemy, Infura, QuickNode, Ankr, Tenderly, or AWS Managed Blockchain Access. This wins when your traffic is bursty, your team is small, or your product spans several EVM networks, because the provider absorbs node upgrades, peering, regional availability, and archive complexity. It costs vendor pricing exposure, rate-limit negotiation, method-level surprises, and dependency on proprietary APIs unless you wrap the provider behind your own adapter.
For most 15-30 person engineering groups, Option 2 wins because the scarce resource is not CPU but attention. The cost is real, but it is easier to cap provider spend than to create senior protocol operations capacity from an already busy product team. Option 1 wins only when the node is part of your product’s defensibility or compliance boundary, because otherwise you are buying operational risk without getting user-visible differentiation.
Do not make this a religious argument about decentralization, because the user-facing reliability question is whether your service can detect bad reads, retry safely, and recover from partial failure. Use two providers in production only if you will actively test failover, because passive redundancy rots and gives false confidence. If you add a secondary RPC, run synthetic transactions, compare block height drift, and alert when providers disagree beyond your chosen threshold.
Good instrumentation is not optional. Track rpc_request_duration_seconds, rpc_error_total, tx_broadcast_total, tx_replacement_total, indexer_lag_blocks, and reorg_depth in Prometheus, then view them in Grafana. Use OpenTelemetry spans around eth_estimateGas, eth_call, eth_sendRawTransaction, and indexer writes because blockchain failures often look like ordinary network latency until they corrupt a workflow.
Your first move should be deleting three outdated assumptions from the backlog
Start by deleting the assumption that you need to own nodes, the assumption that chain choice can be postponed, and the assumption that on-chain events are your application database. Replace them with a one-page failure model: chosen chain, primary RPC, backup RPC, confirmation policy, indexer lag budget, retry rules, and manual recovery path. That document will improve your architecture faster than another infrastructure spike.
