Evolution of Database Architecture: From Single MySQL to Distributed Systems

The story introduces a bank owner who struggles with performance as user traffic grows, using the narrative to explain common database scaling techniques.

Single‑Node MySQL Era

Initially the system stores all data in a single MySQL database, which works for small projects with simple business logic.

Adding Cache Layer

To relieve read pressure, a cache layer is placed between the application and the database, reducing the number of direct database queries.

Master‑Slave Replication (Read‑Write Separation)

When reads outpace writes, the architecture introduces a master (write) database and one or more slave (read) databases, allowing reads to be distributed.

Vertical Splitting of Business Data

Different business domains (e.g., deposits vs. funds) are assigned to separate databases, preventing resource contention between unrelated services.

Horizontal Sharding

Large tables such as order data are split into multiple tables based on a sharding strategy, distributing load across several smaller tables to improve concurrency.

Cluster Deployment

Multiple database instances are deployed as a cluster to increase reliability and handle higher traffic, though raw performance may still be limited.

NoSQL and Search Engines

When relational databases can no longer meet the scale, additional storage technologies are introduced:

Relational data (product basics) remains in MySQL or Oracle .

Document data (descriptions, reviews) moves to document stores like MongDB for better I/O.

Large binary files (images) are stored in distributed file systems such as HDFS .

Searchable text (keywords) uses search engines like ES or Solr .

Hot, high‑frequency data utilizes in‑memory databases like Redis or Tair .

The narrative concludes that these architectural choices allow the bank to handle massive user growth while keeping the system maintainable.