Common Misconceptions About Software Architecture, High Concurrency, and Microservices

With the evolution of software development, ORM and design patterns from the 1990s have been absorbed into mainstream frameworks, while stored procedures are used less, leading to the blending of design patterns into architectural and business patterns.

Misconception 1: A development framework can replace an architect. An architect, formally a "software system architect," focuses on high‑level, holistic design rather than merely code structure. Frameworks provide code architecture, but real architectural decisions depend on human designers who understand requirements and system constraints; without skilled architects, projects become costly and risky.

Misconception 2: High concurrency and big‑data are inherently difficult. The difficulty often stems from inexperienced developers and poor team practices rather than the technology itself. Non‑functional requirements such as scalability and performance surface months after delivery, and without quantifiable testing—such as mock‑based pressure tests—these issues remain hidden until they cause serious problems.

Misconception 3: Microservice architecture is the default solution. Microservices are an evolution of SOA and are not mandatory; they consume more resources, introduce distributed‑transaction consistency challenges, increase cross‑service coupling, and raise deployment and operational costs. Introducing microservices solely to address high concurrency without solving underlying design flaws merely adds new overhead.

The author shares personal experience of building a simple web‑service bus that acted as a lightweight alternative to full‑blown microservices, demonstrating that proper design and incremental solutions often outperform blindly adopting trendy architectures.

Ultimately, there are no programmers who cannot implement a feature; the real challenge lies in cultivating designers who can create reliable, maintainable software and lead teams effectively.