Database Design

// EMBEDDED: orderItems inside order
// Rationale: always fetched together, bounded (max 50 items per order)
const OrderSchema = new Schema({
  tenantId: ObjectId,
  customerId: ObjectId,
  storeId: ObjectId,
  status: String,
  items: [{ // EMBEDDED
    productId: ObjectId,
    name: String,       // denormalized — product name at order time
    price: Number,      // denormalized — price at order time
    quantity: Number,
  }],
  totalAmount: Number,
  __v: Number,          // optimistic locking version
});

// REFERENCED: payments separate from order
// Rationale: queried independently for reconciliation, has own lifecycle
const PaymentSchema = new Schema({
  tenantId: ObjectId,
  orderId: { type: ObjectId, ref: 'Order' }, // reference
  gatewayTxnId: String,
  idempotencyKey: String, // UUID — prevents double-processing
  status: String,
  amount: Number,
  gateway: String, // 'juspay' | 'phonepe' | 'razorpay'
});

MongoDB Replica Set (3 nodes): ┌──────────────┐ │ PRIMARY │ ◀── all writes go here │ (r/w) │ replicates to secondaries └──────┬───────┘ │ replication (oplog streaming) ├──────────────────────┐ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ SECONDARY 1 │ │ SECONDARY 2 │ │ (read-only) │ │ (read-only) │ └──────────────┘ └──────────────┘ ▲ ▲ │ │ Read requests (catalog, store listings, analytics queries) use readPreference: 'secondaryPreferred'

// Mongoose read preference per query
// Reads: go to secondary (reduces primary load)
const stores = await Store
  .find({ tenantId, isActive: true })
  .read('secondaryPreferred');

// Writes and order status reads: always primary (strong consistency)
const order = await Order
  .findOneAndUpdate(filter, update, { new: true })
  .read('primary'); // default, explicit for clarity

Write Amplification & Redis

What write amplification is

Write amplification happens when a single logical write triggers multiple physical writes. In a commerce context: a rider updating their location every 5 seconds writes to riders, triggers a read of all nearby active orders, writes a notification document, pushes to WebSocket — one user action = 4+ DB operations.

How Redis solves it

// WITHOUT Redis: every product page load hits MongoDB
// At 1000 concurrent users browsing: 1000+ DB reads/second
app.get('/stores/:storeId/products', async (req, res) => {
  const products = await Product.find({ storeId, isActive: true }); // always MongoDB
  res.json(products);
});

// WITH Redis cache-aside:
app.get('/stores/:storeId/products', async (req, res) => {
  const cacheKey = `catalog:${storeId}`;

  // 1. Check Redis first (sub-ms)
  const cached = await redis.get(cacheKey);
  if (cached) return res.json(JSON.parse(cached));

  // 2. Cache miss: fetch from MongoDB
  const products = await Product.find({ storeId, isActive: true });

  // 3. Write to cache (TTL 5 min)
  await redis.setex(cacheKey, 300, JSON.stringify(products));

  res.json(products);
});

// On product update: invalidate cache
async function updateProduct(productId, data) {
  const product = await Product.findByIdAndUpdate(productId, data, { new: true });
  await redis.del(`catalog:${product.storeId}`); // invalidate
  return product;
}

Result: 80-90% of product catalog reads served from Redis (~0.1ms) instead of MongoDB (~5-20ms). MongoDB write load drops proportionally.

MongoDB Index Strategy

// Compound indexes — field order matters (ESR rule: Equality, Sort, Range)
// Query: orders by store + status filter + date sort
Order.createIndex({ storeId: 1, status: 1, createdAt: -1 });

// Partial index — only index active stores (reduces index size by ~70%)
Store.createIndex(
  { tenantId: 1, location: '2dsphere' },
  { partialFilterExpression: { isActive: true } }
);

// TTL index — auto-delete expired sessions after 30 days
Session.createIndex({ expiresAt: 1 }, { expireAfterSeconds: 0 });
// MongoDB checks TTL indexes every 60s and deletes expired docs

// TTL for rate limit keys
RateLimit.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 });

// Unique index — prevent duplicate idempotency keys
Payment.createIndex({ idempotencyKey: 1 }, { unique: true });
// Attempting to insert duplicate key → MongoDB throws E11000 → caught → 200 (dedup)

Redis Patterns

Patterns used beyond caching

// 1. SETNX for distributed locks (prevent double payment processing)
const lockKey = `lock:payment:${orderId}`;
const acquired = await redis.set(lockKey, '1', 'NX', 'EX', 30); // 30s TTL
if (!acquired) throw new ConflictError('Payment already processing');
try {
  await processPayment(orderId);
} finally {
  await redis.del(lockKey); // always release
}

// 2. Sorted set for rider leaderboard / analytics
// ZADD adds (score=totalDeliveries, member=riderId)
await redis.zadd('rider:leaderboard', deliveries, riderId);
// Top 10 riders
const top10 = await redis.zrevrange('rider:leaderboard', 0, 9, 'WITHSCORES');

// 3. Pub/Sub for WebSocket fan-out (covered in doc 05)
redis.publish('order:updates', JSON.stringify({ orderId, status, tenantId }));

Connection Pooling

// Mongoose pool: shared across all requests in the Node.js process
// Default pool size = 5, increase for high concurrency
mongoose.connect(MONGO_URI, {
  maxPoolSize: 20,       // max open connections to MongoDB
  minPoolSize: 5,        // keep this many warm (avoids cold connect)
  connectTimeoutMS: 10000,
  serverSelectionTimeoutMS: 5000,
  socketTimeoutMS: 45000,
  // heartbeatFrequencyMS: 10000 — ping MongoDB every 10s to keep alive
});

// ioredis pool (ioredis manages one connection per client instance)
// For Redis cluster, use ioredis.Cluster
const redis = new Redis({
  host: process.env.REDIS_HOST,
  port: 6379,
  maxRetriesPerRequest: 3,
  enableReadyCheck: true,
  lazyConnect: false, // connect immediately on startup
});