When modern architects think about building scalable, high-performance applications in the cloud, Amazon DynamoDB inevitably comes up. DynamoDB is a serverless, fully managed, distributed NoSQL database service with single-digit millisecond performance at any scale. It offers zero infrastructure management, zero downtime maintenance, and zero maintenance windows. Unlike traditional relational databases, DynamoDB encourages a design mindset built around your application’s access patterns rather than rigid table schemas and normalized relationships.
To illustrate DynamoDB concepts, let's imagine a real-world use case: a Medical Test Booking System. In this system, patients can book tests for themselves, multiple tests can belong to a single booking, each test generates results, and doctors provide explanations and descriptions for those results. Every test comes from a predefined set of test types, serving as templates for the booking. This scenario provides a rich example to understand how DynamoDB stores and retrieves data efficiently.
DynamoDB organizes data into tables, which contain items, and each item is made up of attributes. Unlike relational databases, where rows and columns are fixed and relationships are defined by foreign keys, DynamoDB uses a flexible schema where each item can have a different set of attributes. Every item requires a partition key, and optionally, a sort key, which together uniquely identify the item in the table.
Consider a simple table that stores basic patient bookings:
Partition Key (PK) Sort Key (SK) Attributes
PATIENT#123 BOOKING#001 PatientName: John Doe, BookingDate: 2025-12-01
PATIENT#123 BOOKING#002 PatientName: John Doe, BookingDate: 2025-12-15
PATIENT#456 BOOKING#001 PatientName: Mary Jane, BookingDate: 2025-12-03
The partition key distributes data across physical storage partitions to scale horizontally. In the example above, items for PATIENT#123 and PATIENT#456 could reside on different storage partitions, allowing DynamoDB to serve high-volume requests efficiently. The sort key orders related items within the same partition, which enables range queries and efficient retrieval of related items.
Retrieving data in DynamoDB works differently from relational databases. Instead of writing SQL joins to combine tables, DynamoDB encourages you to design tables according to your access patterns. The query operation lets you retrieve items efficiently by specifying the partition key, optionally filtering or sorting with the sort key. In contrast, the scan operation reads every item in the table, filtering results afterward, which consumes significant read capacity and can be slow, especially as your data grows. For this reason, scans with filters should generally be avoided in production systems.
Capacity in DynamoDB is measured in read capacity units (RCUs) and write capacity units (WCUs). A single RCU represents one strongly consistent read per second of up to four kilobytes, and a WCU represents one write per second of up to one kilobyte. You can configure tables for provisioned capacity, where you specify the expected throughput, or on-demand capacity, where DynamoDB scales automatically based on traffic.
Indexes in DynamoDB allow you to create alternative access paths. Local secondary indexes (LSIs) share the same partition key as the base table but allow a different sort key, which is useful when you need multiple ways to order items within a partition. Global secondary indexes (GSIs), on the other hand, can define completely different partition and sort keys, giving you flexibility to query the table in ways not possible with the primary key alone.
For example, in our medical test booking system, we might want to quickly find all tests of a specific type, such as BloodTest. A GSI could be defined where the partition key is TESTTYPE#BloodTest, and the sort key could be BOOKING##TEST#. This index allows doctors or administrators to retrieve all tests of a particular type without scanning the entire table.
Even with just the basics, DynamoDB encourages thinking differently about how data is organized and accessed. A patient’s multiple bookings, the tests within each booking, and the results of those tests can all be stored in a way that minimizes queries, reduces operational overhead, and ensures low latency. While we are only scratching the surface here, the next part of this series will show how to design a single-table schema that consolidates patients, bookings, tests, results, and test type references, optimized for all common access patterns.
DynamoDB shifts the focus from traditional normalization to designing around how your application queries and updates data, which is a profound but liberating change for architects and developers alike. The medical test booking system will serve as a concrete example of this in action in Part 2, where we will explore single-table design and how to structure data efficiently for serverless applications.
