15. Trade-Offs and Common Interview Mistakes
Trade-offs you should be ready to explain
- SQL versus NoSQL: relational constraints and transactions versus data-model and access-pattern flexibility.
- Synchronous versus asynchronous: immediate result and simpler flow versus decoupling and eventual completion.
- Strong versus eventual consistency: stronger read guarantees versus potentially better availability or latency in some distributed designs.
- Cache versus direct database reads: lower repeated-read latency versus invalidation and staleness complexity.
- Monolith versus microservices: simpler deployment and transactions versus independent ownership and scaling with distributed-systems overhead.
- Single-region versus multi-region: simpler consistency and operations versus improved geographic resilience and lower cross-region latency for some users.
- Precomputation versus on-demand computation: faster reads versus storage, freshness, and update cost.
- Push versus pull: lower delivery latency in some workloads versus connection management and polling overhead.
Common mistakes
- Starting with a complex architecture before clarifying requirements.
- Listing technologies without explaining why they are needed.
- Ignoring read/write patterns, data size, and peak traffic.
- Treating a cache as the source of truth without explicit durability guarantees.
- Assuming message queues guarantee exactly-once external side effects.
- Ignoring retries, duplicate requests, and partial failure.
- Using microservices without explaining ownership or deployment benefits.
- Drawing components without tracing data flow.
- Ignoring security, authorization, and tenant isolation.
- Failing to state trade-offs or identify the most important bottleneck.
Strong answer format: 'Given requirement X, I choose component Y because of property Z. The trade-off is W. If the workload changes in condition Q, I would reconsider this decision.'
A strong interview answer is not the one with the most components. It is the one whose decisions follow from requirements and whose failure modes are understood.
Key Takeaways
- Every architectural decision should have a reason and a trade-off.
- Avoid premature microservices and unnecessary infrastructure.
- Discuss failure handling and security alongside the happy path.
- Make assumptions explicit and revise them when requirements change.