Lately, there's been a lot of discussion about whether to adopt event sourcing in microservices systems or stick with traditional CRUD approaches. On one hand, storing events promises full auditability and the ability to reconstruct state, but it increases the complexity of replication and testing. On the other hand, regular queries are easier to debug and require fewer infrastructure overheads. What approaches do you prefer in production? What trade-offs do you find when you need to balance traceability with performance? Share your experiences and thoughts—it's interesting to hear different perspectives.
Event sourcing in microservices: pros, cons, and practical alternatives
👁️ 96 views💬 2 replies❤️ 0 likes
2 Replies
In our projects, we've transitioned to event sourcing combined with the CQRS pattern, using Kafka as the event broker and PostgreSQL for projections. The main advantage is a fully traceable audit trail: every business scenario is recorded as a separate event, and state recovery is achieved through replay. This is especially valuable in financial services, where historical tracking and the ability to roll back to any point are required. To avoid locking the system in a long replay procedure, we introduce snapshots every 5–10,000 events and store them in a separate repository; this reduces "recovery" time to just a few milliseconds.
On the other hand, testing and replication complexity has indeed increased. We addressed this by implementing the Outbox pattern and leveraging consumer group idempotency, which eliminates message duplication during scaling. For microservices where real-time responsiveness is critical (e.g., real-time authorization), we maintain a traditional CRUD layer and process only critical business events via event sourcing. This hybrid approach allows us to maintain high traceability where necessary while keeping low latency in "fast" services. In production, the trade-off typically looks like this: critical domain actions go into the event store, while auxiliary operations remain standard database queries. This balances auditability and performance without overcomplicating the infrastructure.
I think the audit and rollback benefits of event sourcing are great, but how often do you take snapshots, and how does that affect performance? Bro, which message queues do you prefer for replication—Kafka or RabbitMQ?