⚡ Fast & Flexible: Building a To-Do Backend with DynamoDB

Hey Cloud Architects 👋

Welcome to Day 42 of the #100DaysOfCloud Challenge!
Today, we are stepping away from traditional relational databases and exploring the world of NoSQL. The Nautilus DevOps team is building a 'To-Do' application, and we need a storage solution that is both fast and schema-flexible. We'll be using Amazon DynamoDB to store and manage our tasks.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which is perfect for mastering AWS managed services.

---

🎯 Objective

• Provision a DynamoDB table named xfusion-tasks.
• Define a Primary Key (taskId) as a String.
• Manually insert task items with descriptions and progress statuses.
• Verify the data integrity through the AWS Management Console.

---

💡 Why DynamoDB for Modern Apps?

Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability.

🔹 Key Concepts

• Partition Key: A simple primary key, used by DynamoDB's internal hash function to evenly distribute data across partitions.
• Items & Attributes: An "Item" is a group of attributes (similar to a row in SQL), and "Attributes" are the fundamental data elements (similar to columns).
• Serverless: No servers to provision, patch, or manage. You only pay for the storage and throughput you use.

---

🛠️ Step-by-Step: Database Workflow

---

🔹 Phase A: Create the Table

We start by defining our table structure in the DynamoDB console.

• Table Name: xfusion-tasks.
• Partition Key: taskId (Type: String).
• Table Settings: Keep "Default settings" for this task (Provisioned capacity with free tier limits).

---

🔹 Phase B: Populate the Data

Once the table status is Active, we navigate to "Explore items" to add our tasks.

• Create Item 1:
  • taskId: 1
  • description: Learn DynamoDB
  • status: completed

• Create Item 2:
  • taskId: 2
  • description: Build To-Do App
  • status: in-progress

---

🔹 Phase C: Verification

After inserting the items, we must verify they are queryable.

• Scan/Query: In the "Explore items" view, ensure both tasks appear in the results list.
• Status Check: Confirm that Task 1 is marked as completed and Task 2 is in-progress.

---

✅ Verify Success

• Table Existence: The table xfusion-tasks is listed and active in the AWS region.
• Primary Key: The schema correctly identifies taskId as the unique identifier.
• Data Accuracy: Both items are present with the exact attributes defined in the requirements.

---

📝 Key Takeaways

• 🚀 Schema Flexibility: Notice how we didn't have to define "description" or "status" when creating the table only the Primary Key is required!
• 🛡️ On-Demand vs Provisioned: For development, Provisioned (Free Tier) is great, but for unpredictable traffic, On-Demand scaling is a lifesaver.
• 📦 Data Types: Ensure the taskId type matches (String vs Number) otherwise, application-level queries might fail.

---

🚫 Common Mistakes

• Key Mismatch: Trying to insert a task without a taskId or using the wrong data type (e.g., Number instead of String).
• Case Sensitivity: DynamoDB is case-sensitive. taskId is not the same as taskid.
• Over-Provisioning: Setting Read/Write capacity too high can lead to unnecessary costs in a real-world environment.

---

🌟 Final Thoughts

DynamoDB is the go-to choice for serverless architectures. By mastering the console-based setup and item management, you've laid the groundwork for building highly responsive, globally distributed applications.

---

🌟 Practice Like a Pro

Ready to build your own NoSQL backends? Practice here:
👉 KodeKloud Engineer - Practice Labs

---

🔗 Let’s Connect

• 💬 LinkedIn: Hritik Raj
• ⭐ Support my journey on GitHub: 100 Days of Cloud