5.3Database architecture design

A system architect must choose the right database approach and scaling method based on data characteristics (how fixed the structure is, consistency requirements) and access characteristics (the read/write ratio, how data volume grows). In practice, the judgment must rest not on "it's popular" but on the axis of which to prioritize: consistency requirements or scale requirements.

5.3.1Choosing between RDB and NoSQL

• RDB (a relational database) manages data in tabular form according to a predefined schema and guarantees strong consistency through transactions based on ACID properties (atomicity, consistency, isolation, durability). It suits business systems requiring consistency spanning multiple tables (e.g., updating an order and inventory together), but schema changes are costly, and horizontal scaling becomes difficult once vertical scaling on a single node approaches its limit.
• NoSQL does not rigidly fix a schema (key-value, document, column-oriented, graph, etc. stores), and many implementations are designed on the premise of horizontal distribution across multiple nodes. Many products favor BASE properties over strict ACID (prioritizing availability and scalability even at the cost of eventual consistency), suiting requirements with large data volumes, high-frequency access, and a fluid schema (e.g., log data, product catalogs, session data), though many implementations are less capable of guaranteeing strong consistency spanning multiple records.
• The judgment axis is "is strong consistency spanning multiple entities essential to the business?" versus "is horizontal scaling of data/access volume the priority?" Areas where a lack of consistency would be business-critical, such as payments or inventory, favor RDB, while areas that should prioritize write throughput and scalability over consistency, such as large volumes of logs or behavioral history, favor NoSQL—in practice, it is common to mix approaches by area even within a single system (polyglot persistence).

5.3.2Replication and sharding

• Replication is a mechanism that duplicates the same data across multiple nodes (replicas). A typical configuration separates a primary (which accepts writes) from replicas (which hold copies of the primary and are mainly used for reads), spreading read load across multiple nodes while, on primary failure, failing over to a replica to improve data protection and availability. However, because each node holds a copy of the same data, write throughput itself does not increase with the number of replicas (if anything, propagating the copies adds cost).
• Sharding (horizontal partitioning) is a mechanism that splits one large dataset across multiple independent nodes (shards) based on a specific key (e.g., a range or hash of the customer ID). Because each shard holds a different subset of the data, scaling out the number of nodes lets overall write/read throughput and data capacity scale horizontally. On the other hand, choosing the sharding key poorly can create a hotspot where access concentrates on a particular shard, and joins or transactions spanning multiple shards become difficult or costly—design challenges to watch for.
• In short, the judgment axis is: if the challenge is spreading read load and protecting data (availability), use replication; if the challenge is scaling write throughput and data capacity itself, use sharding. In large-scale systems, it is also common to combine both, further replicating each shard for redundancy.

5.3.3Caching and relaxed consistency

• Caching is a mechanism that temporarily holds frequently referenced but infrequently updated data in a layer that can be accessed faster than the primary database (an in-memory store, etc.), reducing read load on the database and shortening response time. Introducing a cache inevitably involves relaxed consistency—the cached data temporarily diverging from the primary database's latest value—so the architect must judge in advance how much staleness the business can tolerate (e.g., a displayed inventory count can tolerate a delay of a few seconds, but a payment balance must be real-time) and select which data is a caching candidate accordingly.

Suppose a system architect is redesigning the database platform for a rapidly growing e-commerce site. First, analyzing the nature of the product catalog, inventory, and order data, they judged that because a consistency failure between order and inventory within the same transaction would be business-critical (e.g., double-selling), this area should keep RDB, which can guarantee strong consistency. Meanwhile, access logs and browsing history involve massive data volume, a fluid schema, and business-tolerable delay/eventual consistency, so the architect adopted NoSQL, built on horizontal distribution, for this area, forming a polyglot-persistence setup. Next, read access to the RDB holding order data (browsing product pages, etc.) surged and reads became the bottleneck, so the architect introduced replication to spread reads across multiple nodes without hurting the primary's write performance, routing read-only queries to replicas. Later still, it turned out that during sales, writes (new orders) themselves began to exceed the capacity of the single primary, a problem replication cannot solve (the limit of write throughput itself), so the architect considered introducing sharding, partitioning order data across multiple nodes keyed on customer ID. At that point, concerned that using a simple sequential customer ID directly as the sharding key would create a hotspot where new customers concentrate on a particular shard, the architect revised the design to distribute using a hashed key instead. Finally, since the "in stock / out of stock" display frequently referenced on product pages was agreed with the business side to be acceptable even with a delay of a few seconds, the architect introduced a caching layer to further reduce read load on the database. As this shows, the core of database architecture design is matching the tool to the nature of the problem: RDB where consistency is essential, replication for spreading read load, sharding for write/capacity limits, and caching for delay-tolerant reads.

5.3.4Section summary

• Choose RDB when strong consistency spanning multiple entities is essential, and NoSQL when horizontal distribution and large/fluid data are the priority (polyglot persistence is also practical)
• Use replication for read-spreading/availability challenges, and sharding for write/capacity-scaling challenges (choose the key carefully to avoid hotspots)
• Caching trades relaxed consistency for shorter response time—select target data within the staleness the business can tolerate