Database access patterns, types, and capacity models

Write the important operations as concrete questions: get an order by ID, list a customer’s recent orders in time order, atomically update inventory and payment state, or read a session by token. Record read/write ratio, consistency, transaction scope, item size, range and join needs, expected rate, growth, tenant skew, and Regional latency. A service name cannot rescue an access model it does not support efficiently.

Relational databases fit SQL constraints, joins, and multi-row transaction requirements. RDS offers managed relational engines; Aurora provides MySQL- or PostgreSQL-compatible relational behavior with distributed cluster storage and reader options. DynamoDB fits key-value/document access designed around partition and sort keys. Its table design begins with known queries; scans and one hot tenant are not solved merely by changing capacity mode. Purpose-built graph, search, time-series, and warehouse services become candidates only when that data model is the hard requirement.

Relational capacity is shaped by instance CPU, memory, connections, storage IOPS and throughput, writer contention, and replica reads. Serverless modes still expose capacity ranges and scaling behavior; serverless means managed elasticity, not absence of limits. DynamoDB offers provisioned and on-demand capacity. Provisioned fits predictable traffic and explicit planning; on-demand reduces planning for variable demand, but partition-key distribution and sudden growth behavior still matter.

For DynamoDB, distribute high-cardinality partition keys and design sort keys or indexes for each required query. Strongly consistent reads are available only on documented resources; global secondary indexes are eventually consistent. For relational systems, choose an engine from application compatibility, SQL features, extensions, licensing, operations, and migration path—not from a generic claim that one engine is faster. Capacity planning uses measured operations, consistency, item size, and peak rate with headroom.

Availability Zones and Regions shape latency and failure scope. A Regional database close to compute usually minimizes application latency. Multi-AZ deployment addresses AZ failure according to the exact database mode; it does not automatically satisfy global latency. Multi-Region replication can improve local reads or writes but adds lag, consistency, conflict, routing, quota, and failback decisions. Select it only when the business requirement justifies those costs.

Architect a portfolio rather than one universal database: an order ledger may remain relational while ephemeral sessions use DynamoDB. Keep security boundaries, encryption, backup, observability, and access controls explicit. Compare total operations and cost only after data model and correctness pass. A low-cost key-value store loses when ad hoc joins are mandatory; a relational cluster loses when a simple high-scale key lookup with predictable access has no relational need. State the decisive model and two rejected models in every design.

In-memory is a database type decision only after durability and reconstruction are explicit. ElastiCache keeps data in memory for low-latency access and can act as a cache or data store, but eviction, node events, and the selected engine or topology define what loss means. It fits a rebuildable leaderboard, session acceleration, counters, or repeatedly read objects when the application has a safe miss and recovery path. It loses as the only order ledger when a missing key would erase an authoritative transaction. Contrast that with DynamoDB, whose key-value persistence and capacity model fit durable known-key records, and with a relational engine, whose joins and constraints fit the order state. Make the branch observable by terminating a cache node or flushing a test key: rebuildable data should repopulate within its latency objective, while authoritative writes must remain intact elsewhere. Protect tenant-specific keys from cross-tenant reuse, restrict network and data-plane access, and never place secrets in an unprotected cache value. Price the memory working set and replicas against avoided database work; an in-memory tier with low hit rate and expensive invalidation is a cost increase, not a performance architecture.