Mastering Common Backend Architecture Patterns: From Single‑DB to Read‑Write Separation

Common system architecture designs are introduced, with emphasis on the first three patterns.

1. Single‑Database Single‑Application Architecture

This is the simplest design, often used in undergraduate projects or small applications, consisting of one database, one business‑logic layer, and an optional admin system.

Advantages: Simple structure, fast development, easy implementation, suitable for first‑version prototypes.

Disadvantages: Poor performance, low availability, limited scalability, unsuitable for large‑scale production.

2. Content‑Delivery Architecture

Widely used by large websites, this pattern employs CDN technology to distribute static resources (HTML, images, CSS, JS) to servers nearest to users, often combined with cloud storage (OSS).

Typical workflow for image upload and retrieval:

User selects a local image and uploads it.

The application uploads the image to cloud storage (OSS) and receives a URL.

The URL is stored in the business database.

When viewing, the application reads the URL from the database.

DNS resolves the URL to the nearest image server.

Smart DNS returns the address of the closest server.

The server returns the image to the application.

The application displays the image.

Advantages: Fast resource download, minimal backend configuration, reduces storage pressure and bandwidth usage.

Disadvantages: OSS and CDN costs can be high for small projects; consistency and update latency may arise due to network delay and CDN sync policies.

3. Read‑Write Separation Architecture

This pattern addresses the performance bottleneck of a single monolithic database by separating write (master) and read (slave) operations, often combined with Elasticsearch for full‑text search.

Scenario 1 – Full‑text Keyword Search: Traditional databases struggle with LIKE queries and full table scans. Elasticsearch offers simple configuration, horizontal scalability, plugin support, and advanced features such as pagination, sorting, faceting, and custom analyzers.

Typical data flow:

Service writes a business record to the primary database.

The record is asynchronously sent to Elasticsearch.

Elasticsearch indexes the record according to defined rules.

When a client queries, the service forwards the request to Elasticsearch, merges results if needed, and returns them to the client.

Scenario 2 – High‑Volume Ordinary Queries: Frequent read‑heavy operations (e.g., balance checks) can overload a single database. By directing writes to the master and reads to replicas, load is distributed; additional replicas can be added horizontally for further scaling.

Typical read‑write flow:

Service writes data to the master.

The master replicates data to one or more slaves (synchronously, asynchronously, or semi‑synchronously).

Read requests are sent to a slave.

Potential issue: replication lag may cause stale reads; a common mitigation is to fall back to the master when data is not yet replicated.

Advantages: Reduces primary database load, provides theoretically unlimited read throughput, improves overall system performance.

Disadvantages: Data latency and consistency challenges.