A grocery delivery platform experiences a sudden multi-week increase in demand well beyond any forecast. Which capacity constraints bind first, and which cannot be solved with autoscaling?

The constraints that bind first

Not compute. Compute is the most elastic resource and generally the least interesting under a demand shock, which surprises teams who plan capacity in terms of instances.

The ones that actually bind:

1. Stateful tier limits. Database connections, write throughput on the primary, and cache memory. These do not scale on demand — adding a replica takes time and does not help writes at all, and resharding is a project.

2. Third-party rate limits. Payment processors, mapping and routing providers, SMS gateways, retailer inventory APIs. These are contractual ceilings, and no amount of internal scaling raises them. Renegotiating takes weeks.

3. Identifiers and defaults sized for the old volume. Partition counts, shard counts, connection pool sizes, queue depth limits, ID ranges. Each was reasonable at the previous scale, each is invisible until it binds, and each requires a change rather than a scale-up.

4. Human operations. Support volume, partner onboarding, fraud review, exception handling. These scale with hiring, which is measured in months.

What cannot be solved with autoscaling at all

The supply side of the marketplace. More demand needs more shoppers and more delivery capacity, and those are people. No infrastructure decision produces them.

This is the constraint that genuinely dominates in a marketplace demand shock, and the architectural response is not capacity but demand shaping:

• Delivery slot availability as an explicit control — the system offers only the capacity that exists, rather than accepting orders it cannot fulfil.
• Dynamic pricing and incentives to attract supply and moderate demand.
• Waitlists and scheduled ordering, converting an immediate demand spike into a schedulable queue.
• Geographic prioritisation, since supply shortages are local rather than uniform.

The architectural insight is that in a marketplace, the honest response to demand exceeding supply is to represent that in the product, not to accept orders and fail them later. Accepting an order you cannot fulfil converts a capacity problem into a trust problem.

What to do structurally, in advance

• Know the ceiling of every stateful component and every third-party limit, written down and monitored against current usage — the assumption register applied to capacity.
• Load-test to failure, not to target, so you know where the cliff is rather than that you clear the bar.
• Ensure everything sized from a volume assumption has that assumption recorded and alerted on, so an approaching limit is a planned change rather than an incident.
• Have a demand-shaping mechanism built and tested before it is needed, because building one during a shock is not possible.