Production Scenario Plan

Every major topic carries a realistic corporate scenario with real numbers. Scenarios are how the course converts "here is a service" into "here is a decision you will have to defend."

1. Scenario format

Each scenario is written to this shape:

Context        the company, the product, the constraint that makes it interesting
The numbers    traffic, data size, growth, latency budget, cost ceiling
The ask        what you are being asked to decide or fix
Naive approach what a competent engineer without AWS depth would do
What breaks    at what scale, and how it manifests
Better design  with the reasoning, not just the answer
Trade-offs     what you gave up
Cost           actual arithmetic, monthly
The interview  how you would present this in 5 minutes

Numbers are internally consistent and defensible. Where a figure is a current AWS limit or price, it is dated and flagged as subject to change.

2. The scenario catalogue

Days 1–3 · Fundamentals

Days 4–7 · Core backend

Days 8–11 · Advanced backend

Days 12–14 · Production and senior

Total: 42 scenarios, at least two per teaching day.

3. The flagship scenario, expanded

S17 — E-commerce at 50,000 orders/minute is the course's recurring backbone. It is introduced on Day 8 and revisited on Days 9, 11, 12, 13 and 14, each time with the lens of that day.

The numbers (fixed, reused throughout)

Why the naive design fails

flowchart LR
    C[Client] --> API[Order API]
    API --> DB[(Orders DB)]
    API --> PAY[Payment provider<br/>p99 2.5s]
    API --> INV[Inventory]
    API --> NOTIF[Email/Push]

At 833 orders/sec with a p99 of 2.5s on the payment hop, the API's own p99 can never be 300ms; worse, the service's threads are held hostage by an external provider, so a provider slowdown becomes a full outage. Order durability is also tied to the payment provider's availability, which is the wrong coupling entirely.

The design the course builds toward

flowchart TB
    C[Client] --> CF[CloudFront] --> AG[API Gateway]
    AG --> OS[Order Service · ECS Fargate]
    OS -->|1 write + outbox, one txn| DB[(Aurora orders)]
    OS -->|2 return 202 + orderId| C
    REL[Outbox relay] -.-> DB
    REL --> EB[EventBridge · OrderPlaced]
    EB --> QP[(SQS payments)] --> PW[Payment Worker]
    EB --> QI[(SQS inventory)] --> IW[Inventory Worker]
    EB --> QN[(SQS notifications)] --> NW[Notification Worker]
    PW --> IDEM[(DynamoDB idempotency)]
    PW --> PROV[Payment provider]
    QP -.->|after N attempts| DLQP[(payments DLQ)]
    PW --> CW[CloudWatch]

The questions each day asks of it

Cost envelope (illustrative, us-east-1, prices dated at publication)

The course then asks the senior question: which three of these lines would you attack first, and what would you give up? (Answers: EventBridge → SNS saves ~$230 but loses routing/replay; batching SQS harder; log sampling; and questioning whether the idempotency table needs on-demand.)

4. Scenario quality rules

1. Numbers must be arithmetically consistent. If peak is 833/sec and the worker handles 40/sec, the design needs ≥21 workers and the text says so.
2. The naive approach must be genuinely plausible — a straw man teaches nothing.
3. Failure must be described as it is experienced, not as a category: "the queue depth chart goes up and to the right and does not come back down" beats "the consumer could not keep up."
4. Every scenario names its trade-off. No scenario resolves into a free win.
5. Prices and limits are dated and marked as verifiable against current AWS docs.

Related

• 11 — Troubleshooting Plan
• 14 — Capstone & System Designs
• 08 — Diagram Plan