Templates/Microservice Event-Driven

Microservice Event-Driven

MicroservicesAdvancedDomain platform

Domain-driven microservices with event sourcing, CQRS-style analytics write path, and dead-letter isolation. Use when services must evolve independently with async integration.

Recommended for: Teams decomposing a monolith into domain services

11 nodes11 connectionsDomain ownershipEvent bus decouplingIndependent deploys

Scope Notes

Intended for Teams decomposing a monolith into domain services at Advanced complexity and Domain platform scope. Treat the graph as a starting shape rather than a fixed stack: keep the topology and the signals below, then swap providers to match your platform.

Domain ownershipEvent bus decouplingIndependent deploys

Review Checklist

0 of 12 reviewed

Use Case

Event-driven microservices, domain-driven design, async integration

Best Fit Scenarios

  • Independent service ownership and deploys
  • Async integration between bounded contexts
  • Analytics fed from domain events

Stack Breakdown

API GatewayAuth ServiceNestJSKafkaPostgreSQLMongoDB

Architecture Layers

1Gateway
2Identity
3Domain services
4Event bus
5Consumers
6Data stores & error isolation

Components by Category

backend

API GatewayAuth ServiceNestJSExpressNotification Service

async

KafkaQueue WorkerDead Letter Queue

database

PostgreSQLMongoDBClickHouse

Why This Topology Works

Each domain service owns its datastore and communicates through Kafka domain events, so services deploy independently. The gateway centralises routing and Auth Service is the single token issuer; Notification and analytics consumers react to events without coupling to the producers.

Scaling Notes

Services scale independently and Kafka partitioning by entity key preserves order per aggregate. PostgreSQL backs the user domain and MongoDB the product catalog; each service owns its own schema.

Observability

Trace requests across service boundaries and watch consumer lag per topic. The DLQ is the inspection surface for events that repeatedly fail.

Typical Bottlenecks

  • Consumer lag during traffic shifts
  • Data ownership boundaries between PostgreSQL and MongoDB
  • DLQ growth caused by event schema drift

Async Flow and Reliability

Commands flow synchronously through the gateway, but cross-domain effects travel as Kafka events. Consumers process independently and unprocessable events park in the DLQ rather than blocking a partition.

Upgrade Path

Add an event store and a dedicated read-model query service if the product needs event sourcing or CQRS, then give Auth Service its own token cache and datastore boundary.