softwarearchitecture softwareengineering systemdesign
SA01.4 - Event Driven Architecture
Debezium
Change data capture allows us to track changes made to a database and react.
We can observe changes written to a database and trigger downstream systems. This pattern is great for event-driven architectures as we can listen to changes and trigger downstream consumers or even replicate the data across our bounded context / microservices.
Listening to changes
-
Change data capture allows us to listen to changes in a database.
-
You can react to these changes to trigger downstream consumers or copy the data into other databases/views.
-
It’s quite a common pattern to listen to changes in a database, change data capture can help us write some resilient, and scalable event-driven architectures, raising events for internal use but also domain events for business consumption.
-
Change data capture patterns can help us reduce the amount of custom code we need to write. E.g. Rather than raising events straight after a Database insert, we can insert and let services/databases give us the change data capture event.
-
Great example of this is using DynamoDB Streams. Data is streamed to consumers in near real-time.
Keeping data in sync
- Change data capture can be used to keep data in sync across many boundaries of your architecture.
- Many architectures have many data sources, change data capture allows us to listen to a change on the “leader” and push these changes to “followers”.
Couple with other design patterns
- When consuming change data capture events, you may want to add layers in between the system consuming it, to enrich or filter the data.
- Example: if your consumer of the event requires additional information you can use enricher pattern to do this.
Replicate data across boundaries
- Your architecture may be split into many boundaries. You can use change data capture pattern to replicate data across boundaries making systems more resilient favouring availability over consistency.
- Replicating data may introduce eventual consistency, given no changes are made your database all listener’s will be eventually consistent. This means data changes across your architecture is async and can take time, it’s important to understand this.