Skip to content
GKgkml.dev
← Learn AWS Cloud

Lesson 6 of 7 · 10 min

Databases and decoupling

Choose a data store by access pattern, and use queues and events to stop components failing together.

Picking a data store

NeedService
Relational, familiar enginesRDS (MySQL, PostgreSQL, SQL Server, Oracle)
Relational with higher throughput and fast replicasAurora
Key-value at any scale, known access patternsDynamoDB
In-memory cacheElastiCache (Redis or Memcached)
Analytical queries over large historyRedshift, or Athena over S3
Time-series, graph, ledgerTimestream, Neptune, QLDB

DynamoDB's one demand

DynamoDB scales without limit provided the partition key spreads traffic. Capacity is allocated per partition, so a low-cardinality or skewed key throttles even when the table has plenty of unused capacity overall — the single most common DynamoDB surprise.

It also means you must know your access patterns before designing the table. Ad-hoc querying and joins are exactly what it is bad at; if the question mentions unpredictable reporting queries, the answer is relational.

The integration services

ServiceModelUse for
SQSQueue — one consumer per messageLoad levelling, buffering, retries
SNSPub/sub — every subscriber gets a copyFan-out to several independent consumers
EventBridgeEvent bus with rule-based routingReacting to AWS and SaaS events
KinesisOrdered, replayable streamHigh-volume telemetry, multiple readers, replay
Step FunctionsState machineMulti-step workflows with retries and approvals

What decoupling actually buys

Putting a queue between a fast producer and a slow consumer means a traffic spike lengthens the queue instead of taking down the backend. The front end stays available even when the downstream is degraded.

The costs are real and must be deliberate: end-to-end latency rises, and standard SQS delivers at least once, so consumers must be idempotent. The usual pattern is recording an idempotency key with a conditional write before acting.

Worth remembering

  • Multi-AZ is availability; read replicas are read scaling. They are not interchangeable.
  • DynamoDB needs the access pattern known when you design the key.
  • A queue converts a hard dependency into a buffered one, at the cost of latency and duplicates.

Test it now

Database selection and queue semantics recur throughout the bank.