I’ve been thinking a lot lately about how modern systems handle scale and complexity. The shift toward distributed, resilient architectures isn’t just theoretical—it’s becoming essential for building applications that can grow and adapt. That’s why I want to share my experience with event-driven systems using Node.js, EventStore, and NATS Streaming.

Have you ever considered what happens when a traditional monolithic database becomes your system’s bottleneck?

Event-driven architecture fundamentally changes how services communicate. Instead of direct API calls, services emit events that other services can react to. This approach creates systems that are loosely coupled, highly scalable, and resilient to failures.

Let me show you how to set up the core infrastructure. First, we’ll use Docker to run our supporting services:

// docker-compose.yml
services:
  eventstore:
    image: eventstore/eventstore:23.6.0
    ports: ["1113:1113", "2113:2113"]
    environment:
      - EVENTSTORE_INSECURE=true

  nats:
    image: nats-streaming:0.25.5
    ports: ["4222:4222", "8222:8222"]

Now, let’s create our EventStore connection in Node.js:

// eventstore-client.js
import { EventStoreDBClient } from '@eventstore/db-client';

const client = EventStoreDBClient.connectionString(
  'esdb://localhost:2113?tls=false'
);

export async function appendEvent(stream, event) {
  const eventData = {
    type: event.type,
    data: event.data,
    metadata: event.metadata
  };
  
  await client.appendToStream(stream, eventData);
}

What if you need to ensure messages aren’t lost, even if a service goes down temporarily?

NATS Streaming provides exactly-once delivery semantics, which is crucial for reliable systems. Here’s how you might set up a publisher:

// nats-publisher.js
import { connect } from 'nats';

const nc = await connect({ servers: 'localhost:4222' });

export async function publishEvent(subject, data) {
  const message = JSON.stringify({
    id: generateId(),
    timestamp: new Date().toISOString(),
    data
  });
  
  nc.publish(subject, message);
}

Building domain models in an event-sourced system requires a different mindset. Instead of storing current state, we store the sequence of events that led to that state:

// user-aggregate.js
class UserAggregate {
  constructor() {
    this.events = [];
    this.state = { active: false };
  }

  createUser(userData) {
    this.applyEvent('UserCreated', userData);
  }

  applyEvent(type, data) {
    const event = {
      type,
      data,
      timestamp: new Date(),
      version: this.events.length + 1
    };
    
    this.events.push(event);
    this.updateState(event);
  }

  updateState(event) {
    switch(event.type) {
      case 'UserCreated':
        this.state = { ...event.data, active: true };
        break;
    }
  }
}

How do you handle situations where multiple services need to coordinate actions?

Saga patterns help manage distributed transactions. Here’s a simple implementation:

// order-saga.js
class OrderSaga {
  async handleOrderCreated(event) {
    try {
      await reserveInventory(event.orderItems);
      await processPayment(event.paymentDetails);
      await confirmOrder(event.orderId);
    } catch (error) {
      await compensateOrder(event.orderId);
    }
  }
}

Monitoring distributed systems requires careful instrumentation. OpenTelemetry provides standardized tracing:

// tracing.js
import { NodeTracerProvider } from '@opentelemetry/sdk-trace-node';
import { JaegerExporter } from '@opentelemetry/exporter-jaeger';

const provider = new NodeTracerProvider();
provider.addSpanProcessor(
  new SimpleSpanProcessor(new JaegerExporter())
);

provider.register();

When deploying to production, consider using Kubernetes for orchestration:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: order-service
        image: order-service:latest
        env:
        - name: EVENTSTORE_URL
          value: "esdb://eventstore:2113"
        - name: NATS_URL
          value: "nats://nats:4222"

Testing event-driven systems requires verifying both event emission and handling:

// order-service.test.js
test('should emit OrderCreated event', async () => {
  const orderService = new OrderService();
  await orderService.createOrder(orderData);
  
  expect(eventStore.getEvents()).toContainEqual(
    expect.objectContaining({ type: 'OrderCreated' })
  );
});

What strategies work best when you need to change event schemas over time?

Schema evolution requires careful planning. Use versioning and transformation layers:

// event-transformer.js
function transformEvent(event) {
  if (event.version === 1) {
    return migrateV1ToV2(event);
  }
  return event;
}

function migrateV1ToV2(oldEvent) {
  return {
    ...oldEvent,
    version: 2,
    data: {
      ...oldEvent.data,
      newField: 'default-value'
    }
  };
}

Building distributed systems challenges us to think differently about consistency, failure, and scale. The patterns I’ve shared here—event sourcing, reliable messaging, and sagas—provide a foundation for creating robust systems.

I’d love to hear about your experiences with distributed architectures. What challenges have you faced? What patterns have worked well for you? If you found this useful, please share it with others who might benefit from these approaches.