Lately, I’ve been thinking about how modern applications handle immense scale and complexity. The challenge isn’t just about writing code that works; it’s about creating systems that remain understandable, maintainable, and scalable over time. This led me to explore a powerful combination: Fastify for its raw speed, EventStore for robust event persistence, and TypeScript for type safety. I want to share a practical approach to building a high-performance, event-driven microservice. If you find this useful, please like, share, and comment with your thoughts.

Event-driven architecture fundamentally changes how services communicate. Instead of direct calls, services produce and consume events. This creates a system where components are loosely connected, making it easier to scale and modify individual parts without disrupting the whole. But how do you ensure these events are stored reliably and replayed correctly?

We’ll build a product inventory system to demonstrate. The core idea is event sourcing: instead of storing just the current state, we record every change as an event. This gives us a complete history of what happened, which is invaluable for debugging and auditing.

Let’s start with the setup. Create a new TypeScript project and install the necessary packages.

npm init -y
npm install fastify @eventstore/db-client typescript
npm install -D @types/node ts-node

Here’s a basic Fastify server setup with TypeScript.

import fastify from 'fastify';

const server = fastify({ logger: true });

server.get('/health', async () => {
  return { status: 'OK' };
});

const start = async () => {
  try {
    await server.listen({ port: 3000 });
    console.log('Server running on port 3000');
  } catch (err) {
    server.log.error(err);
    process.exit(1);
  }
};

start();

Now, let’s connect to EventStore. EventStore is a database designed for event streaming, making it perfect for our use case.

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

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

With the connection ready, how do we structure our domain? We define events that represent state changes. For a product inventory, events might include ProductCreated, StockUpdated, or PriceChanged.

Here’s an example event class in TypeScript.

class ProductCreatedEvent {
  constructor(
    public readonly id: string,
    public readonly name: string,
    public readonly sku: string,
    public readonly initialStock: number
  ) {}
}

When a command comes in, like “create product,” we validate it and store the corresponding event. This event is then used to update the current state and can be processed by other parts of the system.

But what about reading data? Constantly rebuilding state from events can be slow. This is where CQRS comes in. We separate the command side (writing events) from the query side (reading current state). For reads, we maintain a separate, optimized data store that is updated as events occur.

Here’s a simple projection that updates a read model when a ProductCreated event is received.

async function handleProductCreated(event: ProductCreatedEvent) {
  await readModelClient.set(
    `product:${event.id}`,
    JSON.stringify({
      name: event.name,
      sku: event.sku,
      stock: event.initialStock
    })
  );
}

Error handling is critical. Since operations are asynchronous, we need strategies for idempotency (handling duplicate requests safely) and eventual consistency (accepting that read models might be briefly outdated).

Monitoring is another key aspect. We need to track event flow, latency, and errors to ensure the system is healthy and performant.

Deploying such a system requires careful planning. Each component—command handlers, projectors, query APIs—can be scaled independently based on load.

Throughout this process, TypeScript provides confidence by catching type errors early, and Fastify offers a solid, high-performance foundation for our APIs.

Building with events might seem complex at first, but the benefits in scalability and maintainability are substantial. Have you considered how event sourcing could simplify your own application’s data flow?

I hope this gives you a solid starting point for your own event-driven services. Feel free to reach out with questions or share your experiences. If this was helpful, please like, share, and comment below.