Corporate Case Studies

Six realistic systems, each worked end to end: requirements, architecture, configuration, failure modes, monitoring, and the specific mistake a team actually made. Each is written so you could take it into a design review.

1. What you will learn

• See the whole course applied to complete systems rather than isolated features
• Recognise which configuration decisions were forced by which requirement
• Study six distinct failure modes and their resolutions

2. Why this concept exists

• Individual features are easy to understand and hard to combine
• Case studies show the combination, including the trade-offs that only appear at system scale

3. Beginner explanation

• Each case study is a complete story: what the business needed, what was built, what broke, and what changed

4. How it actually works

• Case 1 — Order Processing. API → SQS → order worker → database. Teaches: async API contracts, 202 Accepted, load levelling, basic retry and DLQ
• Case 2 — Payment Processing. Standard queue with strict idempotency, or FIFO with MessageGroupId = accountId. Teaches: at-least-once made safe, transaction boundaries, the external-gateway idempotency key, audit requirements
• Case 3 — Email / Notification Service. API → SQS → notification worker → third-party provider. Teaches: decoupling from an unreliable third party, rate limiting, backoff against a provider quota, per-channel queues
• Case 4 — Large File Processing. S3 → SQS → worker fleet. Teaches: the claim-check pattern, long visibility timeouts and heartbeating, workload distribution, the multipart-upload event trap
• Case 5 — High-Traffic Telecom Events. Millions of events → SQS → large worker pool. Teaches: the full capacity math, autoscaling, backlog management, cost optimisation through batching, quota ceilings
• Case 6 — Legacy Modernisation. Legacy monolith → SQS → new microservice. Teaches: the strangler pattern, the queue as an anti-corruption buffer, schema translation, dual-running and cutover

5. Diagram

• One architecture diagram per case study
• One failure-mode diagram per case study

6. Step-by-step flow

• Each case study follows the same structure:
• 1. Business requirements
• 2. Architecture diagram
• 3. Why this design, and what was rejected
• 4. Queue configuration table with the requirement behind each value
• 5. Code for the interesting parts only
• 6. Failure modes and how each is handled
• 7. Monitoring and alarms
• 8. Scaling behaviour with numbers
• 9. Cost model
• 10. What actually went wrong in production, and the fix

7. Configuration

• Every case study includes its full configuration table so the choices can be compared across cases

8. Production considerations

• Requirements differ far more than architectures do — most of these are the same three boxes with very different settings
• The configuration table is where the design actually lives
• Each case ends with a real mistake, because the mistakes are the most transferable part

9. Common mistakes

• Per case study — each ends with the specific error the team made and what it cost them

10. Real-world example

• The case studies are themselves the examples

11. Interview questions

• ⚫ Walk me through how you would build an order-processing pipeline.
• ⚫ How would you prevent duplicate payment processing at scale?
• ⚫ Design a notification service that depends on an unreliable third-party provider.
• ⚫ Design a file-processing pipeline for files up to 5 GB.
• ⚫ Design for 1,000,000 events per minute.
• ⚫ How would you use SQS to decouple a legacy monolith from new services?

12. Summary

• Six systems, one structure, very different configuration tables
• The requirement → configuration mapping is visible in every case
• Each ends with a genuine production failure and its resolution

Authoring notes

Diagrams to build:

• Six architectures
• Six failure modes

Code samples:

• Per case study: only the parts that are not obvious — the idempotency guard, the heartbeat, the rate limiter, the anti-corruption translator

← Previous: 27 — SQS vs Kafka vs RabbitMQ · Index: Course home · Next: 29 — Hands-on Labs →