📊 NoSQL Database Services - Advanced Strategies

Data Modeling Patterns

Single Table Design (DynamoDB)

// All entities in one table with polymorphic keys
// Partition Key: entityId
// Sort Key: entityType#timestamp

// User entity
{
  PK: 'USER#123',
  SK: 'PROFILE#2024-01-01',
  email: 'user@example.com',
  name: 'John'
}

// Order entity for same user
{
  PK: 'USER#123',
  SK: 'ORDER#2024-01-15',
  orderId: 'ORD-456',
  total: 99.99
}

// Query all data for user
const params = {
  KeyConditionExpression: 'PK = :pk',
  ExpressionAttributeValues: { ':pk': 'USER#123' }
};

// Query specific type
const params = {
  KeyConditionExpression: 'PK = :pk AND begins_with(SK, :prefix)',
  ExpressionAttributeValues: {
    ':pk': 'USER#123',
    ':prefix': 'ORDER#'
  }
};

Document Hierarchy (Firestore)

// Subcollections for related data
/users/{userId}
  /posts/{postId}
    /comments/{commentId}

// Access pattern
db.collection('users').doc('user123')
  .collection('posts').doc('post456')
  .collection('comments').get()

// Denormalization for performance
{
  userId: 'user123',
  userName: 'John', // Denormalized
  post: {
    content: 'Hello',
    likes: 42,
    // Comments stored in subcollection, not here
  }
}

Global Distribution Patterns

DynamoDB Global Tables

Primary Region (US)
  ↓ (Async replication)
Secondary Region (EU)
Secondary Region (APAC)

Eventual consistency between regions
<1 second replication

Firestore Multi-region

Automatic replication across regions
No configuration needed
Read from nearest region

Cosmos DB Global Distribution

const CosmosClient = require("@azure/cosmos").CosmosClient;

const client = new CosmosClient({
  endpoint: "https://account.documents.azure.com:443/",
  key: "key",
  connectionPolicy: {
    preferredLocations: ["East US", "West Europe"]
  }
});

// Reads from preferred location
// Writes to primary region
// Multi-master optional

Performance Optimization

Query Optimization

DynamoDB:

Avoid scans (sequential read)
Use queries with GSI (index)
Projection expressions (read only needed fields)

Firestore:

Index frequently queried fields
Use composite indexes for complex queries
Cache hot data in Realtime DB

Batch Operations

// DynamoDB batch writes
const dynamodb = new AWS.DynamoDB.DocumentClient();

await dynamodb.batchWrite({
  RequestItems: {
    'Users': [
      { PutRequest: { Item: { userId: '1', name: 'Alice' } } },
      { PutRequest: { Item: { userId: '2', name: 'Bob' } } },
      { PutRequest: { Item: { userId: '3', name: 'Charlie' } } }
    ]
  }
}).promise();

// Firestore batch
const batch = db.batch();

batch.set(db.collection('users').doc('user1'), { name: 'Alice' });
batch.set(db.collection('users').doc('user2'), { name: 'Bob' });
batch.set(db.collection('users').doc('user3'), { name: 'Charlie' });

await batch.commit();

Cost Optimization

DynamoDB Pricing Models

Provisioned Mode:
  Read: $1.25 per 100 RCU/month
  Write: $6.25 per 100 WCU/month
  Predictable workloads

Pay-per-Request:
  Read: $1.25 per 1M reads
  Write: $6.25 per 1M writes
  Unpredictable workloads (spiky)

Auto-scaling:
  Automatically adjusts capacity
  Prevents throttling
  Good middle ground

Firestore Pricing Optimization

Delete unused data
  Unused collections = costs

Batch operations
  25 operations = 1 operation

Caching
  Cache frequently read data
  Reduce database reads

Cosmos DB Cost Management

Provisioned throughput (RUs)
  1 RU = 1KB read or write
  Minimum 400 RU/s = ~$24/month
  
Serverless (pay per usage)
  $0.25 per 1M RUs
  Better for unpredictable
  
Scaling strategies:
  Autoscale: 4-100x throughput
  Manual: Fixed RU/s

Transaction Patterns

DynamoDB Transactions

// Limited transaction support (max 25 items)
const dynamodb = new AWS.DynamoDB.DocumentClient();

await dynamodb.transactWrite({
  TransactItems: [
    {
      Put: {
        TableName: 'Accounts',
        Item: { id: '1', balance: 900 }
      }
    },
    {
      Put: {
        TableName: 'Accounts',
        Item: { id: '2', balance: 1100 }
      }
    }
  ]
}).promise();

Firestore Transactions

// Full ACID transactions
db.runTransaction(async (transaction) => {
  const user1Ref = db.collection('users').doc('user1');
  const user2Ref = db.collection('users').doc('user2');
  
  const user1 = await transaction.get(user1Ref);
  const user2 = await transaction.get(user2Ref);
  
  transaction.update(user1Ref, { balance: user1.get('balance') - 100 });
  transaction.update(user2Ref, { balance: user2.get('balance') + 100 });
});

Monitoring and Alerting

DynamoDB Monitoring

Metrics to track:
- ConsumedReadCapacityUnits: Alert > 80% provisioned
- ConsumedWriteCapacityUnits: Alert > 80% provisioned
- UserErrors: Alert on any
- SystemErrors: Alert on any
- ThrottledRequests: Alert > 0

Firestore Monitoring

Metrics:
- Read operations: Track growth
- Write operations: Track growth
- Delete operations: Optimize
- Bytes read: Monitor costs

Key Takeaways

• **Single table design** (DynamoDB) requires careful planning

• **Document hierarchy** (Firestore) more intuitive

• **Global tables essential** for multi-region apps

• **Batch operations** reduce latency and costs

• **Pricing models differ** - choose based on workload pattern

• **Transactions critical** for money/inventory operations

• **Monitoring prevents surprises** - cost and performance

• **Denormalization tradeoff** - speed vs storage

• **Cold data archival** reduces long-term costs

• **Cache aggressively** - most apps have hot data

Provider Recommendation Matrix