I'm preparing an interview design and implementation for a system that accepts writes, stores the data in a database, and records events. The system should be highly available, support availability across multiple zones, and scale elastically as demand changes. I'm considering two approaches: an API Gateway connected to Lambda and DynamoDB, or a containerized Python service running on EC2 instances across auto scaling groups behind a load balancer, with PostgreSQL as the database. I need to present a working solution along with a design document explaining decisions, trade-offs, and anything I could not fully implement. How should I choose between these architectures and justify the decision?
4 Answers
A good design document can present one primary architecture and one alternative rather than trying to implement both fully. For example, choose the managed serverless version for the working prototype, explain that it minimizes operational components, and list when you would move to containers and PostgreSQL—such as requiring complex relational transactions, specialized queries, or tighter control over runtime behavior. Include a failure-mode table covering duplicate requests, partial failures, zone loss, traffic spikes, and database throttling.
For a simple write-and-store workload, API Gateway, Lambda, and DynamoDB is likely the easier solution to implement and defend. The managed services provide multi-zone availability, automatic scaling, and less operational work. Use a stable event or request ID to make retries idempotent, and consider buffering or asynchronous processing if callers do not need the database write to complete synchronously. Discuss throttling, retry behavior, monitoring, and what happens when a downstream service is unavailable.
The container and PostgreSQL option gives you more control over application behavior, SQL queries, transactions, and portability, but it also creates more work. You would need multiple availability zones, health checks, automatic scaling, deployment strategy, database backups, failover or replication, connection pooling, and a plan for database capacity. A load balancer and auto scaling group alone do not make the whole system highly available if the database is a single failure point.
If you choose this route, call out the database as the hardest part. Scaling stateless application instances is straightforward; scaling writes and recovering from a database failure require much more design.
Start by defining the decision criteria before choosing a design. Even if the requirements are intentionally open-ended, state reasonable assumptions for availability, peak and average write rates, acceptable latency, durability, and whether duplicate events are allowed. Then compare both options against those assumptions. The strongest interview answer is usually not a single universally correct architecture, but a clear set of trade-offs and an explanation of why your choice fits the assumed workload.
You can explicitly label the numbers as assumptions and explain how the design would change if the workload or availability target increased. That demonstrates structured thinking without pretending the requirements were provided.
The main caveat is that serverless scaling does not remove capacity limits. You still need to consider API, Lambda concurrency, and database throughput limits, plus how sudden spikes are handled.