Use Data Stores In Application Development | 🏗️ Build A Product Catalog API

Exam Guide: Developer - Associate

🏗️ Domain 1: Development with AWS Services

📘 Task 3: Use Data Stores In Application Development

DynamoDB dominates this task. The need to understand table design, key selection, indexing, consistency models, and how to write efficient queries is essential. As well as caching with ElastiCache and DAX. Plus specialized stores like OpenSearch.

📘 Concepts

DynamoDB Key Concepts

Primary Keys

Every table needs one. Two options:

• 
  Simple primary key: Partition key only (PK). Each item has a unique PK.


• 
  Composite primary key: Partition key (PK) + Sort key (SK). Multiple items can share a PK if they have different SKs.

Partition Key Selection

The partition key determines which physical partition stores your data. A good partition key has high cardinality which refers to many distinct values so that the data spreads evenly.

Consistency Models

Query vs Scan

FilterExpression does NOT reduce the amount of data read. It only filters what's returned to you. You still pay for the full scan/query. To reduce reads, use better key design or GSIs.

Global Secondary Index (GSI) vs Local Secondary Index (LSI)

GSI Projection Types:

• 
  ALL: all attributes (most flexible, most storage cost)


• 
  KEYS_ONLY: only key attributes (cheapest)


• 
  INCLUDE: keys + specified attributes (balanced)

Caching Options

Specialized Data Stores

Data Lifecycle

DynamoDB TTL

Automatically deletes expired items at no cost. Eventually consistent (up to 48 hours delay).

S3 Lifecycle Policies

Transition objects between storage classes (Standard → IA → Glacier) or expire them after a set time.

🏗️ Build A Product Catalog API

Now let's put these concepts into practice by builidng a Product Catalog API backed by DynamoDB:

• A DynamoDB table with a composite primary key and a Global Secondary Index (GSI)


• A Lambda function that performs queries, scans, and writes


• TTL configured for automatic data expiration


• DAX caching in front of DynamoDB


• A clear understanding of when to use query vs scan, GSI vs LSI, and strong vs eventual consistency

Prerequisites

• 
  to set a time a few minutes in the future for testing.
  
  
  
  

  💡 TTL deletion is eventually consistent: items may persist for up to 48 hours after expiration. Don't rely on TTL for exact timing. Always filter out expired items in your queries as a safety measure.

  
  
  
  
  
  

  
  
  
  Part VII
  

  
  
  

  
  
  
  Caching with DAX
  

  
  
  

  
  

  DAX (DynamoDB Accelerator) is an in-memory cache that sits in front of DynamoDB. It's a drop-in replacement. Same API, just change the client endpoint.

  
  

  
  
  

  
  
  
  When to Use DAX
  

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  Scenario	Use DAX?
  Read-heavy workload, same items queried repeatedly	Yes
  Microsecond response times needed	Yes
  Write-heavy workload	No (DAX is a read cache)
  Need strongly consistent reads	No (DAX returns eventually consistent)
  Diverse access patterns, rarely same item twice	No (low cache hit rate)

  
  
  

  
  
  
  How DAX Works
  

  
  
  
  
  
  
  

  CODE Kopieren

  Without DAX:
  
    App → DynamoDB (single-digit millisecond reads)
  
  
  
  With DAX:
  
    App → DAX (microsecond reads if cached) → DynamoDB (on cache miss)
  
  

  
  
  
  
  
  
  
  

  
  
  
  Console Walkthrough (Don't Create.Just Understand)
  

  
  
  

  
  

  💸 DAX requires a VPC and costs money even when idle. We'll walk through the setup without creating it.

  
  

  
  
  

  Step 01: Click ▼ DAX

  
  
  

  Step 02: Click Create cluster

  
  
  
  
  
  • 
    Cluster name: product-cache
    
  
  
  • 
    Node type family: t-type family
    
  
  
  • 
    Node type: dax.t3.small
    
  
  
  • 
    Cluster size: 3 nodes (for high availability)
    Click Next
    
  
  
  
  
  

  Step 03: Configure networks

  
  
  
  
  
  • 
    Network Type: IPv4
    
  
  
  • 
    Subnet group: Create new
    
  
  
  • 
    Subnet group name: MySubnetGroup
    
  
  
  • 
    VPC ID: defaultVPC
    
  
  
  • 
    Subnets: Select all
    
  
  
  • 
    Security group: default ▼
    Click View in EC2 console
    
  
  
  
  
  

  Step 04: Allow port 8111 from your Lambda functions

  
  
  

  ✅Green banner: Inbound security group rules successfully modified on security group

  
  
  

  Step 05: Configure Security

  
  
  
  
  
  • 
    IAM Service role for DynamoDB access: Create new
    
  
  
  • 
    IAM role name: DaxToDynamoDB
    Click Next → Click Next → Click Create cluster
  
  
  
  
  

  ✅Green banner: Successfully created the cluster product-cache.

  
  
  

  Step 06: In your Lambda code, you'd change one line:
  
  

  
  
  
  
  

  CODE Kopieren

  # Without DAX
  
  dynamodb = boto3.resource('dynamodb')
  
  
  
  # With DAX — same API, just different endpoint
  
  import amazondax
  
  dax_client = amazondax.AmazonDaxClient(
  
      endpoints=['product-cache.abc123.dax-clusters.us-east-1.amazonaws.com:8111']
  
  )
  
  table = dax_client.Table('ProductCatalog')
  
  # All your existing code works unchanged!
  
  

  
  
  
  
  
  
  
  

  
  

  DAX is a drop-in replacement for DynamoDB reads. Same API, same code. Just change the client. 💡 But remember: DAX only supports eventually consistent reads and is for read-heavy workloads.

  
  

  
  
  
  
  
  

  
  
  
  🏗️ What You Built | 📘Exam Concepts Recap
  

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  What You Did	Exam Concept
  Designed a table around access patterns first	Access-pattern-driven DynamoDB design
  Created a composite primary key (PK + SK)	Single-table design, sort key relationships
  Added a Global Secondary Index with different keys	GSI for alternate access patterns
  Used overloaded keys (PRODUCT#, CATEGORY#, REVIEW#)	Single-table design pattern
  Queried by partition key with begins_with on sort key	Efficient query operations
  Ran a scan and compared Count vs ScannedCount	Scan is expensive: it reads the entire table
  Added a FilterExpression to a scan	Filters run AFTER reading: don't save capacity
  Used Decimal(str(price)) instead of float	DynamoDB type system: no float support
  Toggled ConsistentRead=True on get_item	Strongly vs eventually consistent reads
  Noted GSIs only support eventual consistency	GSI limitations
  Enabled TTL on a ttl attribute	Automatic data lifecycle management
  Walked through DAX setup	Read caching for DynamoDB, microsecond latency

  
  
  
  
  
  

  
  
  
  ⚠️ Clean Up Protocol
  

  
  
  

  1. DynamoDB → Delete the ProductCatalog table
  
  2. Lambda → Delete ProductCatalogAPI
  
  3. IAM → Delete the Lambda execution role
  
  4. CloudWatch → Delete the log groups

  
  
  
  
  
  

  
  
  
  Key Takeaways
  

  
  
  
  
  
  1. 
     Partition key cardinality: high cardinality = even distribution = good performance
  
  
  2. 
     Query > Scan: always prefer query. Scan reads the entire table.
  
  
  3. 
     FilterExpression doesn't save reads: it filters after reading. Use key design or GSIs instead.
  
  
  4. 
     GSIs can be added anytime. LSIs must be created with the table
  
  
  5. 
     GSIs are eventually consistent only: no strongly consistent reads on GSIs
  
  
  6. 
     Use Decimal, not float for DynamoDB numbers in Python
  
  
  7. 
     TTL is free but eventually consistent (up to 48 hours delay)
  
  
  8. 
     DAX = DynamoDB read cache (microsecond reads). Same API as DynamoDB.
  
  
  9. DAX doesn't support strongly consistent reads
  
  
  10. 
      Single-table design with overloaded keys is the recommended DynamoDB pattern
  
  
  
  
  
  
  
  

  
  
  
  Additional Resources
  

  
  
  
  
  
  
  
  
  
  • Using Time to Live (TTL) in DynamoDB
  
  
  
  
  
  
  
  

  🏗️

  Vollständiger Original-Artikel

  Den kompletten Beitrag mit allen Details direkt auf dev.to lesen.

  ↗ Original-Artikel auf dev.to lesen