Why Simple, Terminology‑Free Design Beats Complex Architecture Patterns

The author, responsible for designing and building large systems such as Uber's distributed payment platform and Skype on Xbox One, describes how these projects are thoroughly designed, iterated, and documented before implementation, involving hundreds of engineers.

Despite the scale, the designs do not rely on standard architecture tools: no UML, 4+1 model, ADR, C4, or dependency graphs are used. Simple boxes and arrows suffice, and diagrams often vary in layout and are edited by different engineers.

There are no dedicated software or enterprise architects in the teams; senior engineers write code alongside junior ones and actively participate in design discussions, challenging decisions and proposing alternatives.

The teams also avoid formal architecture patterns and terminology from classic literature (e.g., microservices, serverless, event‑driven architecture), using only the most direct tools like Google Docs or Office365 for documentation.

Software Design in Tech Companies and Startups

Most tech companies and startups follow a similar approach:

Start from the business problem. Define what problem to solve, what product to build, why, and how success is measured.

Brainstorm solutions. Conduct small‑scale meetings, moving from high‑level ideas to detailed ones.

Explain on a whiteboard. One person sketches the preferred approach, ensuring the whole team can understand the architecture from top‑down.

Document with simple diagrams and text. Use clear language without heavy jargon; Uber uses an RFC‑style document with a basic template.

Discuss trade‑offs. Evaluate alternatives, explain why certain patterns (e.g., monolith vs. microservice) are chosen, and outline pros and cons.

Distribute the design for feedback. Share the document with all engineers, set reasonable feedback windows, and incorporate useful comments.

This method differs from many architecture guidelines mainly in the cultural aspect: high autonomy and flat hierarchies enable engineers to contribute directly without waiting for architect approval.

Simple, Terminology‑Free Software Design Beats Architecture Patterns

The goal of system design should be simplicity. Simpler systems are easier to understand, debug, and implement. Descriptions should be clear enough for the least experienced team member to grasp.

Simple design mirrors simple code: single responsibility, clear naming, and understandable conventions. While design patterns can be helpful, they should not dominate the solution; use them only when they naturally arise.

Understanding common architecture patterns can speed up discussions, but they are tools, not goals. Over‑reliance on patterns can lead to forcing a pattern onto a problem, which is counterproductive.

How to Design Systems Better?

Write your design on a whiteboard with a colleague. Explain what you are doing and why, and gather their input.

Record the design in a simple document and share it. Use a format that others can comment on, such as Google Docs or Office365.

Produce two alternative designs and compare them. Explain the trade‑offs and why one is preferred.

Be explicit about the trade‑offs you make. State the constraints and what you optimized for.

Review others' designs and learn from them. Ask questions, challenge assumptions, and suggest simpler alternatives.

The best software design is simple and easy to understand. When starting a new project, focus on creating a design that anyone can quickly comprehend rather than chasing formal patterns or documentation.

Original source: Software Architecture is Overrated, Clear and Simple Design is Underrated – https://www.infoq.cn/article/NKLNc0HHtZNaviOX2VdV