A 90-minute meeting where my design got torn apart in the most constructive way possible. Here's what I learned about thinking in systems.

#Architecture #Career #Design Review

The Review

The architecture review was for a feature I'd been designing for three weeks — a real-time notification system that needed to push updates from the backend to connected frontend clients. I'd designed it carefully: WebSocket connections managed by a connection pool on the backend, a pub/sub layer for routing messages, and a React context on the frontend that components could subscribe to. The design document was 12 pages long, with diagrams and sequence flows and a detailed explanation of every component. I was proud of it, and I walked into the review expecting approval with maybe a few minor suggestions. What I got instead was 90 minutes of questions that exposed every assumption I'd made without realizing it, and by the end, the design was substantially different — and substantially better — than what I'd walked in with.

The questions that changed the design weren't about the happy path. They were about failure modes: what happens when a WebSocket connection drops mid-message, how does the system handle a client that reconnects after being offline for an hour, what's the behavior under load when 10,000 clients are connected simultaneously. I had answers for some of these but not all, and the gaps revealed that I'd designed for the case where everything works and hadn't thought deeply about the cases where it doesn't. The senior engineer leading the review didn't criticize — he asked questions, and the questions themselves were the education, because they taught me to think about the system the way he thought about it: not as a flow that works, but as a system that has to keep working when things go wrong.

That review was the moment I started thinking like a senior engineer. The shift wasn't about learning specific techniques — it was about adopting a different stance toward design. Instead of "does this work?", the question became "what happens when this fails?", and that question, applied recursively to every component, is what separates a design that survives production from one that works in a demo. I've carried that question into every design review I've done since, both as a presenter and as a reviewer, and it's the single most valuable design principle I've learned. Design for failure, not just for success, because failure is when the design actually matters.