Contrarian

You always hear “start with the requirements” in system design, but i was reminded recently why that advice exists. a mock interview prompt i was trying was to design ticketmaster. easy to default into the standard checklist of microservices, redis, api gateway, multiple databases. but i forced myself to take a contrarian approach: if the system only served 10k users a day, most of that setup would be overkill. a single well-structured app and a decent cache would’ve done the job. The point isn’t that microservices are bad. it’s that architecture is contextual. scaling patterns only make sense once there’s something worth scaling. So always useful to take a beat and start by asking: “what’s the real traffic, latency, and team size here?” if it’s small, i keep it simple. if it grows, i evolve it. “Start with requirements” sounds obvious until you actually apply it. Incidentally, this approach helped me with trade-off analysis also. Hope this helps