## Architecture and Data-Scaling Trade-offs This is a conceptual systems discussion. The interviewer wants to see that you understand two fundamental "compare two approaches and choose" decisions: the **application architecture** decision (microservices vs. monolith) and the **database scaling** decision (sharding vs. replication). For each, define the terms precisely, contrast them, and explain which problem each one actually solves. ### Constraints & Assumptions - Answer at the level of an engineer making a real design decision, not a textbook recital — emphasize **trade-offs and when to choose what**. - Use concrete examples where they sharpen the point. - These are independent decisions: you might run a monolith with a sharded database, or microservices with replicated read replicas. ### Clarifying Questions to Ask - What is the **team size and org structure**? (Conway's law makes microservices pay off mainly when many teams need to deploy independently.) - What is the **current scale and growth trajectory** — are we solving a real bottleneck or a hypothetical one? - For the database: is the pressure on **read throughput**, **write throughput / total data volume**, or **availability**? Each points to a different strategy. - What are our **consistency** requirements (can reads tolerate staleness)? ### Part 1: Microservices vs. Monolithic Architecture Compare microservices and monolithic architectures. Define each, contrast them across deployment, scaling, data ownership, and failure modes, and explain **in which business/engineering scenarios you would choose one over the other**. ```hint Frame the trade-off Don't frame it as "microservices = modern/good." Frame it as a trade between *simplicity and locality* (monolith) versus *independent deployability and team autonomy* (microservices) — bought at the cost of distributed-systems complexity (network, partial failure, data consistency, ops overhead). ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 2: Database Sharding vs. Replication Define **sharding** and **replication**, explain how they differ, and state **what problem each one solves**. Be explicit that they are complementary, not alternatives. ```hint Where to start Ask yourself: does each node hold the *same* data, or a *slice* of it? That distinction is the key to defining both terms, and to figuring out which bottleneck each one is built to relieve. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - A team adopts microservices but every feature still requires changing three services at once and they deploy together. What went wrong, and what would you do? (Probes premature/incorrect service boundaries — the "distributed monolith.") - Your read replicas are lagging and users complain that data they just saved "disappears" on refresh. Explain the cause and two ways to fix it. - How do you choose a shard key, and what goes wrong if you pick a poor one (e.g. shard by `country` for a user table)? - When would you deliberately stay on a monolith and a single (vertically scaled) database despite growth?