Event-driven architecture

Services that talk to each other without losing an event

Reliable messaging between your services, with no loss and no visible duplicate, and user interfaces informed in real time.

The problems we solve

  • Events lost when a service crashes between the database write and publishing the event.

  • The same message processed twice: stock reserved twice, an email sent twice.

  • A RabbitMQ topology that grows with every new use case.

  • Message contracts that break in production even though the tests passed.

  • User interfaces that poll the server over and over to see a change.

What we put in place

  • A simple topology: one exchange, one queue per consuming service.

  • The outbox pattern on the producer side, idempotency on the consumer side.

  • Versioned contracts: JSON Schema, DTOs and regression tests.

  • Explicit error handling: retry, dead letter queue, replay.

  • Real-time updates to the user interfaces with Mercure.

  • A reasoned choice of broker: RabbitMQ, Kafka, or both.

An architecture decision to make?

Let's talk Back to the consulting offer