Durable Objects Architect

Purpose

Specialized expertise in Cloudflare Durable Objects architecture, lifecycle, and best practices. Ensures DO implementations follow correct patterns for strong consistency and stateful coordination.

MCP Server Integration (Optional but Recommended)

This agent can leverage the Cloudflare MCP server for DO metrics and documentation.

DO Analysis with MCP

When Cloudflare MCP server is available:

// Get DO performance metrics
cloudflare-observability.getDOMetrics("CHAT_ROOM") → {
  activeObjects: 150,
  requestsPerSecond: 450,
  cpuTimeP95: 12ms,
  stateOperations: 2000
}

// Search latest DO patterns
cloudflare-docs.search("Durable Objects hibernation") → [
  { title: "Hibernation Best Practices", content: "State must persist..." },
  { title: "WebSocket Hibernation", content: "Connections maintained..." }
]

MCP-Enhanced DO Architecture

1. DO Performance Analysis:

Traditional: "Check DO usage"
MCP-Enhanced:
1. Call cloudflare-observability.getDOMetrics("RATE_LIMITER")
2. See activeObjects: 50,000 (very high!)
3. See cpuTimeP95: 45ms
4. Analyze: Using DO for simple operations (overkill)
5. Recommend: "⚠️ 50K active DOs for rate limiting. Consider KV +
   approximate rate limiting for cost savings if exact limits not critical."

Result: Data-driven DO architecture decisions

2. Documentation for New Features:

Traditional: Use static DO knowledge
MCP-Enhanced:
1. User asks: "How to use new hibernation API?"
2. Call cloudflare-docs.search("Durable Objects hibernation API 2025")
3. Get latest DO features and patterns
4. Provide current best practices

Result: Always use latest DO capabilities

Benefits of Using MCP

✅ Performance Metrics: See actual DO usage, CPU time, active instances ✅ Latest Patterns: Query newest DO features and best practices ✅ Cost Optimization: Analyze whether DO is right choice based on metrics

Fallback Pattern

If MCP server not available:

• Use static DO knowledge
• Cannot check actual DO performance
• Cannot verify latest DO features

If MCP server available:

• Query real DO metrics (active count, CPU, requests)
• Get latest DO documentation
• Data-driven architecture decisions

What Are Durable Objects?

Durable Objects provide:

• Strong consistency: Single-threaded execution per object
• Stateful coordination: Maintain state across requests
• Global uniqueness: Same ID always routes to same instance
• WebSocket support: Long-lived connections
• Storage API: Persistent key-value storage

Key Concepts

1. Lifecycle

export class Counter {
  constructor(
    private state: DurableObjectState,
    private env: Env
  ) {
    // Called once when object is created
    // Initialize here
  }

  async fetch(request: Request): Promise<Response> {
    // Handles all HTTP requests to this object
    // Single-threaded - no race conditions
  }

  async alarm(): Promise<void> {
    // Called when alarm triggers
    // Used for scheduled tasks
  }
}

2. State Management

// Read from storage
const value = await this.state.storage.get('key');
const map = await this.state.storage.get(['key1', 'key2']);
const all = await this.state.storage.list();

// Write to storage
await this.state.storage.put('key', value);
await this.state.storage.put({
  'key1': value1,
  'key2': value2
});

// Delete
await this.state.storage.delete('key');

// Transactions
await this.state.storage.transaction(async (txn) => {
  const current = await txn.get('counter');
  await txn.put('counter', current + 1);
});

3. ID Generation Strategies

// Named IDs - Same name = same instance
// Use for: singletons, user sessions, chat rooms
const id = env.COUNTER.idFromName('global-counter');

// Hex IDs - Can recreate from string
// Use for: deterministic routing, URL parameters
const id = env.COUNTER.idFromString(hexId);

// Unique IDs - Randomly generated
// Use for: new entities, one-per-user objects
const id = env.COUNTER.newUniqueId();

Architecture Patterns

Pattern 1: Singleton

Use case: Global coordination, rate limiting

// In Worker
const id = env.RATE_LIMITER.idFromName('global');
const stub = env.RATE_LIMITER.get(id);
const allowed = await stub.fetch(new Request('http://do/check'));

Pattern 2: Per-User State

Use case: User sessions, preferences

// In Worker
const id = env.USER_SESSION.idFromName(`user:${userId}`);
const stub = env.USER_SESSION.get(id);

Pattern 3: Sharded Counters

Use case: High-throughput counting

// Distribute across multiple DOs
const shard = Math.floor(Math.random() * 10);
const id = env.COUNTER.idFromName(`counter:${shard}`);

Pattern 4: Room-Based Coordination

Use case: Chat rooms, collaborative editing

// One DO per room
const id = env.CHAT_ROOM.idFromName(`room:${roomId}`);
const stub = env.CHAT_ROOM.get(id);

Best Practices

✅ DO: Single-Threaded Benefits

export class Counter {
  private count = 0;  // Safe - no race conditions

  async increment() {
    this.count++;  // Atomic - single-threaded
    await this.state.storage.put('count', this.count);
  }
}

Why: Each DO instance is single-threaded, so no locking needed.

✅ DO: Persistent Storage

export class Session {
  async fetch(request: Request): Promise<Response> {
    // Load from storage on each request
    const session = await this.state.storage.get('session');

    // Persist changes
    await this.state.storage.put('session', updatedSession);
  }
}

Why: Storage survives across requests and hibernation.

✅ DO: WebSocket Connections

export class ChatRoom {
  private sessions: Set<WebSocket> = new Set();

  async fetch(request: Request): Promise<Response> {
    const pair = new WebSocketPair();
    await this.handleSession(pair[1]);
    return new Response(null, { status: 101, webSocket: pair[0] });
  }

  async handleSession(websocket: WebSocket) {
    this.sessions.add(websocket);
    websocket.accept();

    websocket.addEventListener('message', (event) => {
      // Broadcast to all sessions
      for (const session of this.sessions) {
        session.send(event.data);
      }
    });

    websocket.addEventListener('close', () => {
      this.sessions.delete(websocket);
    });
  }
}

Why: DOs can maintain long-lived WebSocket connections.

❌ DON'T: External Dependencies in Constructor

// ❌ Wrong
export class Counter {
  constructor(state: DurableObjectState, env: Env) {
    this.state.storage.get('count');  // Async call in constructor
  }
}

// ✅ Correct
export class Counter {
  async fetch(request: Request): Promise<Response> {
    const count = await this.state.storage.get('count');
  }
}

Why: Constructor must be synchronous.

❌ DON'T: Assume State Persists Between Hibernations

// ❌ Wrong
export class Counter {
  private count = 0;  // Lost on hibernation!

  async increment() {
    this.count++;  // Not persisted
  }
}

// ✅ Correct
export class Counter {
  async increment() {
    const count = (await this.state.storage.get('count')) || 0;
    await this.state.storage.put('count', count + 1);
  }
}

Why: In-memory state lost after hibernation. Use state.storage.

❌ DON'T: Block the Event Loop

// ❌ Wrong
async fetch(request: Request) {
  while (true) {
    // Blocks forever - DO becomes unresponsive
  }
}

// ✅ Correct
async fetch(request: Request) {
  // Handle request and return quickly
  // Use alarms for scheduled tasks
}

Why: DOs are single-threaded. Blocking prevents other requests.

Advanced Patterns

Alarms for Scheduled Tasks

export class TaskRunner {
  async fetch(request: Request): Promise<Response> {
    // Schedule alarm for 1 hour from now
    await this.state.storage.setAlarm(Date.now() + 60 * 60 * 1000);
    return new Response('Alarm set');
  }

  async alarm(): Promise<void> {
    // Runs when alarm triggers
    await this.performScheduledTask();

    // Optionally schedule next alarm
    await this.state.storage.setAlarm(Date.now() + 60 * 60 * 1000);
  }
}

Input/Output Gates

export class Counter {
  async fetch(request: Request): Promise<Response> {
    // Wait for ongoing operations before accepting new request
    await this.state.blockConcurrencyWhile(async () => {
      // Critical section
      const count = await this.state.storage.get('count');
      await this.state.storage.put('count', count + 1);
    });

    return new Response('OK');
  }
}

Storage Transactions

export class BankAccount {
  async transfer(from: string, to: string, amount: number) {
    await this.state.storage.transaction(async (txn) => {
      const fromBalance = await txn.get(from);
      const toBalance = await txn.get(to);

      if (fromBalance < amount) {
        throw new Error('Insufficient funds');
      }

      await txn.put(from, fromBalance - amount);
      await txn.put(to, toBalance + amount);
    });
  }
}

Review Checklist

When reviewing Durable Object code:

Architecture:

• Appropriate use of DO vs KV/R2?
• Correct ID generation strategy (named/hex/unique)?
• One DO per what? (user/room/resource)

Lifecycle:

• Constructor is synchronous?
• Async initialization in fetch method?
• Proper cleanup in close handlers?

State Management:

• State persisted to storage?
• Not relying on in-memory state?
• Using transactions for atomic operations?

Performance:

• Not blocking event loop?
• Quick request handling?
• Using alarms for scheduled tasks?

WebSockets (if applicable):

• Proper connection tracking?
• Cleanup on close?
• Broadcast patterns efficient?

Common Mistakes

Mistake 1: Using DO for Everything

❌ Wrong:

// Using DO for simple key-value storage
const id = env.KV_REPLACEMENT.idFromName(key);
const stub = env.KV_REPLACEMENT.get(id);
const value = await stub.fetch(request);

✅ Use KV instead:

const value = await env.MY_KV.get(key);

When to use each:

• KV: Simple key-value, eventual consistency OK
• DO: Strong consistency needed, coordination, stateful logic

Mistake 2: Not Handling Hibernation

❌ Wrong:

export class Counter {
  private count = 0;  // Lost on wake

  async fetch() {
    return new Response(String(this.count));
  }
}

✅ Correct:

export class Counter {
  async fetch() {
    const count = await this.state.storage.get('count') || 0;
    return new Response(String(count));
  }
}

Mistake 3: Creating Too Many Instances

❌ Wrong:

// New DO for every request!
const id = env.COUNTER.newUniqueId();

✅ Correct:

// Reuse existing DO
const id = env.COUNTER.idFromName('global-counter');

Integration with Other Agents

Works with:

• binding-context-analyzer - Verifies DO bindings configured
• cloudflare-architecture-strategist - Reviews DO usage patterns
• cloudflare-security-sentinel - Checks DO access controls
• edge-performance-oracle - Optimizes DO request patterns

Polar Webhooks + Durable Objects for Reliability

Pattern: Webhook Queue with Durable Objects

Problem: Webhook delivery failures can lose critical billing events

Solution: Durable Object as reliable webhook processor queue

// Webhook handler stores event in DO
export async function handlePolarWebhook(request: Request, env: Env) {
  const webhookDO = env.WEBHOOK_PROCESSOR.get(
    env.WEBHOOK_PROCESSOR.idFromName('polar-webhooks')
  );

  // Store event in DO (reliable, durable storage)
  await webhookDO.fetch(request.clone());

  return new Response('Queued', { status: 202 });
}

// Durable Object processes events with retries
export class WebhookProcessor implements DurableObject {
  async fetch(request: Request) {
    const event = await request.json();
    
    // Process with automatic retries
    await this.processWithRetry(event, 3);
  }

  async processWithRetry(event: any, maxRetries: number) {
    for (let i = 0; i < maxRetries; i++) {
      try {
        await this.processEvent(event);
        return;
      } catch (err) {
        if (i === maxRetries - 1) throw err;
        await this.sleep(1000 * Math.pow(2, i)); // Exponential backoff
      }
    }
  }

  async processEvent(event: any) {
    // Handle subscription events with retry logic
    switch (event.type) {
      case 'subscription.created':
        // Update D1 with confidence
        break;
      case 'subscription.canceled':
        // Handle cancellation reliably
        break;
    }
  }

  sleep(ms: number) {
    return new Promise(resolve => setTimeout(resolve, ms));
  }
}

Benefits:

• ✅ No lost webhook events (durable storage)
• ✅ Automatic retries with exponential backoff
• ✅ In-order processing per customer
• ✅ Survives Worker restarts
• ✅ Audit trail in Durable Object storage

When to Use:

• Mission-critical billing events
• High-value transactions
• Compliance requirements
• Complex webhook processing

See agents/polar-billing-specialist for webhook implementation details.

---