DEV Community: Ravisankar.ponugoti

7 Essential DynamoDB Fundamentals Every AWS User Should Know !!!!!!!

Ravisankar.ponugoti — Thu, 08 Oct 2026 17:52:01 +0000

DynamoDB is a cloud-based NoSQL database that stores information in a key-value format. As a non-relational database, it does not use structured tables like traditional relational databases, allowing for greater flexibility and scalability. This allows applications to quickly access and manage large amounts of data without performance issues.

Understanding DynamoDB’s core features is important for using it effectively in AWS-based systems. This post covers key DynamoDB concepts to help you build scalable and cost-efficient NoSQL solutions. 💡

Primary Keys
DynamoDB uses partition keys or composite primary keys (partition key + sort key) to uniquely identify records. 🔑

✅ Partition Key as the Primary Key
If a table has only a partition key, records are retrieved by directly referencing the key value.

📌 Example: A table storing video games, where the partition key is the game title:

Press enter or click to view image in full size

Here, each record is uniquely identified by Game Title, and fetching a record requires providing the exact primary key value. ✨

✅ Composite Primary Key: Partition Key + Sort Key
For more complex data structures, a table may include both a partition key and a sort key, forming item collections.

📌 Example: A table where the partition key is Developer, and the sort key is Game Title:

Press enter or click to view image in full size

This enables efficient Query operations, which retrieve multiple items from an item collection rather than scanning the entire table. ⚡

📚 Worth to check:
Core components of Amazon DynamoDB
Learn about the building blocks of DynamoDB your app will need. You'll discover the basics of tables, items…
docs.aws.amazon.com

📚 Alex Debrie — The DynamoDB Book

How to Access Data in DynamoDB

Item-Based Actions (GetItem, PutItem, UpdateItem, DeleteItem) Work on single records. Require specifying the full primary key. Batch Operations (BatchGetItem, BatchWriteItem) Effectively perform multiple item-based actions. BatchGetItem supports up to 100 items, while BatchWriteItem supports up to 25 items per operation. 🚀
Query API Action Retrieves multiple records within the same partition key = operates on item collection. Always requires specifying PK. Faster than Scan because it targets a specific subset of data.
Scan API Action ⚠️ Reads the entire table, making it slow and expensive. Should be avoided unless absolutely necessary. 📌 Code Examples: AWS DynamoDB Query & Scan Examples

Secondary Indexes: Unlocking More Query Power
DynamoDB supports Global Secondary Indexes (GSI) and Local Secondary Indexes (LSI), enabling flexible query patterns beyond the primary key.

Learn about Medium’s values
✅ Global Secondary Index (GSI)

Allows querying on non-primary attributes.
Uses a different partition key and optional sort key.
Supports eventual consistency by default.
Requires additional read/write capacity.
Use case: Fetching all orders by CustomerID in an e-commerce app.
✅ Local Secondary Index (LSI)

Uses the same partition key but a different sort key.
Reads can be either eventually consistent or strongly consistent.
Must be created at table creation.
Shares base table’s read/write capacity.
Use case: Fetching all blog posts by an author, sorted by date.
📌 Key Differences

DynamoDB Streams: Reacting to Changes in Real-Time
DynamoDB Streams allow you to respond to changes occurring in a DynamoDB table in real time. Every modification in the table is sent to a stream, which can then be filtered and processed further.

For example, the stream data can be linked to an EventBridge Pipe for event filtering and later on linked with AWS Lambda function to trigger automated actions based on updates.

Press enter or click to view image in full size

DynamoDB Streams can be integrated with multiple AWS services, including Lambda, Kinesis, EventBridge, SQS, and SNS, making them a powerful tool for event-driven architectures, logging, and replication.

Amazon DynamoDB Accelerator (DAX): Supercharge Your Reads
DAX is a caching service designed for DynamoDB, reducing read latency from milliseconds to microseconds. Ideal for applications with high read frequency. ⚡

Synchronous & Event Driven

Ravisankar.ponugoti — Tue, 29 Sep 2026 19:13:34 +0000

Synchronous Architecture

caller -----> api Gateway ------> lambda ------> DynamoDB

caller call the api -> api calls this lambda ----> that lambda goes to a database DynamoDB

in this case , the caller invoke this api and wait for response during the same invocation
this type of architecture is called synchronous architecture.

example:-
Synchronous flow

What happens step by step?

Suppose the caller sends:

GET /user/123

Caller → API Gateway**

The caller says:

"Give me the details of user 123."

API Gateway → Lambda**

API Gateway invokes Lambda synchronously.

Meaning:

"Lambda, execute this function and give me the result."

Lambda → DynamoDB**

Lambda asks DynamoDB:

"Give me user 123."

DynamoDB → Lambda**

DynamoDB returns the data.

Lambda → API Gateway → Caller**

Lambda returns the result, and API Gateway sends it back to the caller.
The important part

Yes, the caller waits for the HTTP response.

So your statement can be improved to:

"In a synchronous architecture, the caller sends a request to API Gateway and waits for the response. API Gateway synchronously invokes Lambda. Lambda processes the request, accesses DynamoDB, and returns the result through API Gateway to the caller as part of the same request-response flow."

Modernizing public sector applications using serverless and containers

Ravisankar.ponugoti — Thu, 24 Sep 2026 19:14:45 +0000

100,000 students. One "Enroll" button. 🎓

Here's how I'd design the backend on AWS using serverless, events, and containers 👇

1️⃣ The request

Student → Website → API Gateway → Lambda

Lambda checks the basics: is the student valid, is the course open, is enrollment allowed? There's no server to keep running 24/7. It runs when a request arrives, and AWS handles scaling and patching.

2️⃣ The trap

Once enrollment succeeds, it's tempting to have Lambda call Payment, the student database, email, faculty alerts, and analytics directly. That's tight coupling. If the email service goes down, the whole flow can suffer.

3️⃣ The fix: publish an event

Instead of calling everyone, Lambda announces one thing: "StudentEnrolled" 📣

Lambda is the producer, EventBridge is the broker, and the Payment, Database, and Notification services are the consumers.

Producer produces → Broker distributes → Consumer consumes.

Want fraud detection or analytics later? Add a new consumer. The enrollment service doesn't change. That's loose coupling.

4️⃣ Where containers come in

Say the Payment service grows into Java, Spring Boot, libraries, and a payment SDK. Package it all into a container, then choose where it runs:

☸️ EKS if your team already runs Kubernetes

🚢 ECS if you want AWS-native orchestration with fewer decisions to make

5️⃣ Where Fargate fits (where many beginners get confused)

ECS and EKS decide how your containers are orchestrated. Fargate is the serverless compute underneath, so you don't manage, patch, or scale servers.

My one-line memory hook: Lambda = serverless code, Fargate = serverless containers.

What would you plug in as the next consumer of the StudentEnrolled event?

AWS #Serverless #SystemDesign #EventDrivenArchitecture #Containers