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).