The idea
“Does it work?” hides three different questions. Reliability asks whether the system keeps doing the right thing when something goes wrong. Scalability asks what happens as load, data, or complexity grows. Maintainability asks whether people can understand, operate, and change it over time.
These qualities overlap, but they are not substitutes. Adding servers may help with load while making operations harder. A beautifully organized codebase may still lose data during a machine failure. Good design names the pressure before choosing the remedy.
Make it concrete
Suppose a checkout service handles 100 requests per second. Reliability work might retry a safe operation after a transient failure. Scalability work might partition traffic when demand rises tenfold. Maintainability work might give operators clear traces and keep the retry policy in one understandable place. Each action improves a different kind of future.
Start with the failure story
A productive design review describes scenarios instead of praising technologies. What if a database node disappears? What if traffic spikes for an hour? What if a new engineer must change the workflow next year? Concrete stories expose tradeoffs that “highly scalable architecture” does not.
Try it
Take one system you use. Write one sentence each for its most credible reliability failure, growth pressure, and maintenance burden. Which one deserves attention first—and what evidence would change your mind?