A blockchain infrastructure provider serves RPC requests where a small number of query types are enormously more expensive than the rest. How should the request path be structured?
Show the answer Hide the answer
The load shape
Requests are not comparable. A current block-height query is trivially cheap and cacheable for a second. A balance lookup is a single indexed read. A historical log query over a wide block range can consume seconds of CPU and gigabytes of I/O. They arrive through the same endpoint with the same shape, so an undifferentiated request path lets the expensive minority determine the experience of everyone.
The structure that works
- Classify at the gateway, by method and by parameters. Range size, block depth and result cardinality are all knowable before execution, and classification must happen before any expensive resource is committed.
- Separate pools per class. Cheap, cacheable queries served from a read-optimised tier; expensive historical queries on a separate pool with their own capacity and their own queue. A shared pool means one archive query holds a connection that a thousand height checks needed.
- Cache aggressively where the answer is immutable. Anything about a finalised block never changes, which is an unusually good caching property, and it should be exploited with long TTLs and immutable keys.
- Per-key rate limits weighted by cost, not by request count. Counting requests treats a height check and an archive scan identically, which is exactly wrong. A cost-weighted budget is the only limit that reflects the resource.
- Reject unbounded queries at admission rather than timing them out after consuming resources. A timeout still pays for the work.
The consistency dimension
A node that is behind the chain head answers confidently and wrongly. Liveness must be measured as progress relative to the network, not as process health, and a lagging node must be removed from rotation. This is the same failure as a stale read replica, with the difference that the answer looks authoritative.
The economic layer
Because request costs vary by orders of magnitude, flat pricing per request is a business model that subsidises the expensive minority. Compute-unit pricing aligns the incentive and — more usefully — gives customers a signal that changes their query patterns, which no technical control achieves as effectively.