A 2 GB video should never touch your app servers.
The API hands out a presigned URL: one key, PUT only, 15 minutes. The client uploads straight to storage; the queue carries only the key.
300 ms
of radio time for one home screen
Six calls in three dependent waves, ~100 ms per mobile round trip. One aggregated call costs one round trip plus a fast fan-out inside.
One API for web, mobile and TV?
Bad: One shared API
It serves web, mobile and TV badly.
Good: A backend per client type
One BFF per client type, owned by that client’s team.
The export takes minutes. Don’t make the client wait.
Reply 202 Accepted with a status URL and Retry-After. The client polls; when the work is done, 303 See Other points to the report.
Reads and writes look different? Separate the models.
Orders go to one write model; an outbox feeds projectors that build a read model per screen, so queries never join. The price is projector lag.
OTPs and promotional messages share one notification queue. A big promo batch lands first.
The fix
A priority queue. OTPs get their own lane and more consumers, so they never wait behind promos.
Replace a monolith route by route.
A routing façade sends migrated routes to new services and the rest to legacy. An anti-corruption layer translates the old model. Every stage ships and can be reversed.
Event sourcing for a settings page?
Bad: Replay everything
You pay for event versioning, projections and erasure on an append-only log.
Good: Plain CRUD
Nothing needs replay. Keep event sourcing for ledgers and audit trails.
Remember
Name the problem before the pattern. Valet keys and claim checks keep bytes off your servers; 202 plus a status URL for slow jobs; CQRS where reads differ; strangle legacy route by route.