Eight Common Software Architecture Design Patterns and Their Advantages and Disadvantages

1. What Is Architecture

Architecture is likened to a human skeleton: it provides the fundamental support for software just as a skeleton supports the human body, with muscles, nerves, and skin built on top.

2. What Is a Design Pattern

A design pattern is accumulated experience that helps solve recurring problems efficiently, saving design time and improving productivity.

The author lists eight common patterns used in practice:

Single‑Database Single‑Application Pattern

Content Distribution Pattern

Query Separation Pattern

Microservice Pattern

Multi‑Level Cache Pattern

Sharding (Split‑Database‑Split‑Table) Pattern

Elastic Scaling Pattern

Multi‑Datacenter (Multi‑Site) Pattern

3. Single‑Database Single‑Application Pattern

This is the simplest pattern, often used for small projects or prototype versions. It typically consists of one database, one business‑logic layer, and one admin system.

Advantages: simple structure, fast development, suitable for first‑version prototypes.

Disadvantages: poor performance, low availability, limited scalability.

4. Content Distribution Pattern

Common in large websites, this pattern uses CDN and cloud storage (OSS) to deliver static resources (HTML, images, CSS, JS) from the nearest server to the user.

Typical workflow: upload → store in OSS → save URL in DB → DNS resolves the nearest edge node → serve the resource.

Advantages: fast resource download, reduced backend storage pressure.

Disadvantages: higher cost, possible consistency and update‑latency issues.

5. Query Separation Pattern

Addresses heavy read/write pressure on a single database by separating read and write operations, often using master‑slave replication and optionally Elasticsearch for full‑text search.

Typical flow: write to master → async sync to slave(s) → reads go to slaves; for full‑text search, data is also indexed in ES.

Advantages: improved read performance, scalability, and specialized search capabilities.

Disadvantages: data latency and consistency challenges.

6. Microservice Pattern

Decomposes a monolithic system into independent services, each with its own database, cache, and possibly ES. Communication happens via RPC (synchronous) or MQ (asynchronous).

Benefits: reduced database pressure, isolated failures, independent deployment, clearer team boundaries (Conway’s law), and easier scaling.

Drawbacks: increased complexity, need for high‑availability RPC/MQ, data consistency, and careful service boundary design.

7. Multi‑Level Cache Pattern

Caches are placed at three layers: client side, API gateway, and backend services (e.g., Redis, Memcached). This reduces latency and backend load.

Advantages: handles massive read traffic, lowers backend pressure.

Disadvantages: cache consistency issues and potential cache‑stampede when caches expire.

8. Sharding (Split‑Database‑Split‑Table) Pattern

Splits a large table or database horizontally (by range or hash) or vertically to distribute load across multiple hosts.

Advantages: reduces single‑table pressure.

Disadvantages: distributed transaction complexity and extensive code refactoring.

9. Elastic Scaling Pattern

Uses an elastic scaling service (e.g., VM pool, Docker) to dynamically add or remove instances based on load, solving sudden traffic spikes.

Advantages: elastic resource usage, cost‑effective for peak periods.

Disadvantages: requires applications to be horizontally scalable and adds operational complexity.

10. Multi‑Datacenter (Multi‑Site) Pattern

Deploys services in multiple geographic data centers to achieve high availability and low latency for global users.

Advantages: high availability, high performance, and multi‑region active‑active deployment.

Disadvantages: data synchronization, consistency, and routing challenges.

In conclusion, the eight architecture patterns each have distinct strengths and weaknesses; selecting the right combination depends on business requirements, traffic characteristics, and team capabilities.

For more detailed discussions, the author invites readers to join the architecture community via the provided technical groups.