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

  1. Starting with a complex architecture before clarifying requirements.
  2. Listing technologies without explaining why they are needed.
  3. Ignoring read/write patterns, data size, and peak traffic.
  4. Treating a cache as the source of truth without explicit durability guarantees.
  5. Assuming message queues guarantee exactly-once external side effects.
  6. Ignoring retries, duplicate requests, and partial failure.
  7. Using microservices without explaining ownership or deployment benefits.
  8. Drawing components without tracing data flow.
  9. Ignoring security, authorization, and tenant isolation.
  10. 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.