Absorb flash-sale order bursts without losing messages

Challenge brief

Brightline Supply runs its order API on ECS, and each request writes the order straight into an RDS for PostgreSQL instance that downstream fulfilment and finance both read. During last month's flash sale arrivals jumped from 40 to 900 orders a second; the database saturated, API latency climbed, and about 3,000 checkout requests timed out and were never recorded. The platform lead wants arrival spikes held durably until the database can take them, and any order that keeps failing parked somewhere the on-call engineer can inspect rather than retried forever. Fulfilment and finance already query the relational order tables, so RDS must stay the system of record. Which architecture should the platform lead adopt?

Success criteria

• 1.Add one source queue so arrivals are stored instead of blocking on the database.
• 2.Add a worker fleet to drain the queue at a rate the database can sustain.
• 3.Keep RDS as the system of record; fulfilment and finance query it directly.
• 4.Add a dead-letter queue so an order that exceeds maxReceiveCount can be inspected.
• 5.Connect the source queue through the workers to the RDS order tables.
• 6.Connect the source queue's redrive path to the dead-letter queue.
• 7.Remove the key-value store; this change may not rewrite the order data model.

Service palette