Why Microservices, Multi‑Cache, and Sharding Can Solve Your Scaling Nightmares

Continuing from the previous article on six common system architectures, this piece focuses on the last three patterns: microservices, multi‑level cache, and sharding.

Microservices Architecture

Microservices have become a hot trend, yet many adopt them without understanding the motivations or trade‑offs. The author shares personal pain points with a monolithic system, such as increasing write load on a single database, single points of failure, tangled codebases, frequent full‑project rebuilds, inter‑departmental conflicts, and difficulty managing permissions.

To address these, the company split the system into independent vertical services, each with its own database, cache, and auxiliary components (e.g., Elasticsearch). Services communicate synchronously via RPC and asynchronously via MQ.

By isolating functionality, each sub‑system reduces database pressure, limits failure impact to its own domain, enables independent code repositories, allows targeted deployments, clarifies departmental responsibilities (Conway's law), shields other services from schema changes via stable APIs, and simplifies permission management. The author notes that while most issues are resolved, new challenges arise, such as the need for highly reliable RPC/MQ, network latency, and data consistency.

Key takeaways: high performance, strong scalability, and high availability for medium‑to‑large companies, but increased architectural complexity requires strong overall design leadership.

Multi‑Level Cache Architecture

This pattern tackles extreme read traffic by adding caches at three layers: client side, API gateway, and backend services.

Client‑side caching (browser cache, cookies, local storage for web; local DB or memory for apps) provides near‑zero latency. If a miss occurs, the request proceeds to the API gateway, where another cache can reduce backend load. Backend services use traditional caches such as Redis, Memcached, or in‑memory JVM caches.

Advantages: absorbs massive read bursts and eases pressure on backend servers. Drawbacks: cache invalidation can cause data‑consistency issues and, if multiple cache layers expire simultaneously, may lead to a sudden surge of requests (cache avalanche).

Sharding (Database Partitioning) Architecture

Sharding distributes a single logical table across multiple databases to alleviate write, read, and storage bottlenecks. The article focuses on horizontal sharding.

The diagram shows a table split across several databases (red boxes). Key concepts are defined: a host is a physical or virtual machine; an instance is a database process (e.g., MySQL) that can host multiple databases; a database (库) contains tables; a table (表) holds the actual data.

Effective sharding requires sufficient hardware resources, careful selection of sharding keys, and handling of cross‑shard queries. The author emphasizes that sharding is usually a later‑stage evolution when a single database can no longer meet performance or capacity needs.

Overall, the article provides practical insights into when and how to adopt these three architectural patterns, warning against over‑splitting and stressing the importance of balanced design.