I'm preparing for a system design interview where I need to build a service that accepts writes, stores the data in a database, and records events. The solution should be highly available, support multiple availability zones, and scale up or down as demand changes.
I'm considering two approaches:
1. API Gateway → Lambda → DynamoDB
2. A containerized Python application running on EC2 instances in an Auto Scaling group, behind a load balancer, with PostgreSQL as the database
I need to present a working implementation along with a design document. Some parts may not be practical to implement fully, so I'll document those decisions. How should I compare these architectures, choose one, and justify the trade-offs?
3 Answers
The container and PostgreSQL design can also work, but you have more responsibilities: deploying across multiple zones, health checks, load balancing, instance scaling, database backups, failover, connection limits, patching, and capacity planning. PostgreSQL may be the better choice if you need relational queries, transactions across multiple entities, or existing SQL compatibility.
For the event side, consider whether events must be written synchronously with the main record. A queue or event stream can absorb traffic spikes and let consumers process events asynchronously. If the event is critical, define retry behavior, idempotency, and what happens when a consumer or downstream service is unavailable.
Start by defining the assumptions you’ll use. Even if the prompt doesn’t provide traffic or availability numbers, state reasonable targets for write rate, latency, uptime, retention, and acceptable data loss. Then explain how the design meets those targets and what you would change if the assumptions increased.
For a simple write-and-event service, the serverless option is usually easier to make highly available and elastic. API Gateway, Lambda, and DynamoDB are managed services with built-in scaling and multi-zone durability, so there’s less infrastructure to operate. The trade-off is less control over runtime behavior, database queries, and some limits around execution time and throughput.
There isn’t one universally correct architecture without requirements, but there should be a clear decision process. Keep the first version as simple as possible, identify the bottlenecks, and explain how it evolves. For either design, discuss retries, duplicate writes, idempotency keys, monitoring, alarms, backups, recovery objectives, and failure scenarios.
A useful presentation would show the normal request path, what happens during a zone failure, how a sudden traffic spike is handled, and what happens when the database or event processor is unavailable. Also call out service limits and assumptions instead of claiming that the system is infinitely scalable.
You don’t need invented numbers to produce a valid design, but you should explicitly say that the requirements are missing and choose provisional assumptions. The important part is showing how those assumptions influence the architecture and how you would validate them.