Hi Andy, you are right that Event Sourcing and event-driven system are different things. Its indeed possible to use event-driven architectures without Event Sourcing. I actually feel that is more appropriate for most use-cases (see my response to Farrel’s comment).

Using purely event-driven principles to decouple microservices at the data level without Event Sourcing is possible but not something I recommend doing without ample research on how to deal with failures.

As soon you start duplicating data in multiple microservices, there will be potential consistency issues. Not talking about eventual consistency here (because that’s a given when data “lives” in multiple places), but lasting consistency issues in scenario’s where a microservice is faulty/buggy, and therefore unable to process the asynchronous data update events.

Given you have proper logging/alerting, this is easy to detect, but it’s not that straightforward to deal with. With Event Sourcing, the fault/buggy service can be hotfixed, and by replaying the event stream the data inconsistency can be resolved.

Without Event Sourcing, you would need another way to deal with this issue. While not impossible, it’s not easy. One potential solution with Apache Kafka would be to have the consumer that are not able to process events write to a dead letter queue with leaky buckets and reprocess the events after the microservice is hotfixed. This gets complex fast.