Event Sourcing und CQRS sind zwei populäre Entwurfsmuster für die Umsetzung von Microservices-Architekturen. Beim Event Sourcing wird nicht nur der letzte Zustand eines Objekts gespeichert, sondern alle Events, die den Zustand eines Objekts beeinflussen. Ist der aktuelle Zustand eines Objekts gefordert, dann kann dies durch das Abspielen aller gespeicherten Ereignisse in der korrekten Reihenfolge jederzeit erzeugt werden. Im Gegensatz dazu verfolgt CQRS das Prinzip, schreibende Operationen (Command) und lesenden Operationen (Query) strikt voneinander zu trennen und dafür unterschiedliche Datenbanken bzw. Datenmodelle einzusetzen. Event Sourcing und CQRS werden häufig in Kombination eingesetzt. Während CQRS auch ohne Event Sourcing genutzt werden kann, ist Event Sourcing ohne CQRS weniger sinnvoll. Um Event Sourcing implementieren zu können, ist ein sogenannter Event Store notwendig, der die notwendigen Eigenschaften von Event Sourcing effizient zur Verfügung stellt. Was genau ist ein Event Store, und was muss er leisten? Ist ein Event Store auch notwendig, wenn man Event Sourcing mit CQRS kombiniert? Diese Präsentation zeigt erst auf, was ein Event Store an Eigenschaften mitbringen sollte. Danach wird gezeigt, inwieweit sich mit Apache Kafka ein Event Store sinnvoll umsetzen lässt und darauf eingegangen, was ein dezidiertes Event Sourcing Framework wie Axon für zusätzliche Vorteile bietet.