A recommendation platform must ingest billions of interaction events daily without the ingestion path becoming a bottleneck. Which throughput techniques matter most, and which common approach limits scale?

The approach that limits scale

Per-event synchronous processing. Each event triggering a database write, an index update and a downstream call means throughput is bounded by the slowest synchronous step, and every component must scale to the full event rate.

It is the natural first implementation and it caps the system at a fraction of what the same hardware could deliver.

What matters most

1. Batching, at every layer. Clients batch events before sending; the ingestion tier batches writes; consumers batch downstream calls. Batching amortises fixed per-operation costs — network round trips, transaction overhead, index updates — over many events, and frequently improves throughput by an order of magnitude for a small, bounded latency cost.

The critical parameter is the maximum batch-formation delay, which bounds the latency price. Batch by size or time, whichever comes first.

2. Partitioning with an appropriate key. Partition by user id gives per-user ordering — sufficient for almost all personalisation logic — without a global ordering bottleneck. Global ordering would serialise everything, which is the other common scale limiter.

3. Decouple ingestion from processing. The ingestion path does one thing: durably accept and acknowledge. All expensive work happens asynchronously behind the log. Ingestion throughput is then bounded by write bandwidth rather than by the slowest consumer.

4. Append-only storage. Sequential writes are dramatically faster than random ones, and log-structured engines are built for this workload.

5. Backpressure rather than unbounded buffering. When consumers fall behind, the correct response is to signal upstream, not to accumulate. An unbounded buffer converts a throughput problem into a memory exhaustion problem and, worse, into an unbounded latency problem — telemetry arriving hours late is not delayed, it is worthless.

The constraint teams discover late

Hot partitions. A viral item or a bot-driven user concentrates traffic on one partition. Aggregate throughput looks healthy while one partition is saturated and its consumers fall behind.

This requires per-partition monitoring rather than aggregate monitoring, and a strategy — key salting for the hot key, or dedicated handling — planned in advance, because partition count is difficult to change on a live system.

The trade-off to state

Every technique here trades latency for throughput. Batching adds delay. Asynchronous processing means results are not immediately visible. Backpressure means rejecting work.

That trade is correct for ingestion, where completeness and cost matter more than immediacy. It would be wrong on the serving path, where the budget is tens of milliseconds — which is precisely why the two paths are separated.