@RaulJuncoV: System design interviews are 80% questions and 20% diagrams. The better you clarify, the better your architecture becom…

System design interviews are 80% questions and 20% diagrams. The better you clarify, the better your architecture becomes. A weak candidate hears: “Design a notification system.” Then immediately draws: API → Queue → Worker → Database A strong candidate starts asking: 1- How many users? 2- What types of notifications? 3- Email, SMS, push, or all three? 4- Real-time or delayed? 5- Can notifications arrive more than once? 6- Do we need ordering? 7- What happens when a provider fails? 8- Can users configure preferences? 9- How long must we retain delivery history? The questions are the design. Everything after is just drawing what you learned. Each answer changes the architecture: - High traffic may require partitioning. - Strict ordering affects queue design (usually per user or per key) - Retries require idempotency. - Multiple providers need failover. - User preferences add filtering. - Delivery history adds storage and retention decisions. The diagram should not come from memory. It should come from the constraints you uncover. In a system design interview, asking better questions does three things: -> It reduces ambiguity. -> It exposes trade-offs. -> It shows how you think. Requirements first. Architecture second. What other questions do you like?