Legacy systems of record rarely emit events. They mutate rows, run nightly batches, and expose file drops. Introducing an event-driven backbone across an estate like that is less about message brokers than about establishing a trustworthy source of change and a contract that downstream consumers can rely on for years.
Getting events out of a system that does not produce them
Three mechanisms cover most cases. Change data capture reads the database transaction log and emits row-level changes with no application modification — the least invasive option, and the one that produces the most technical, least business-meaningful events. The transactional outbox writes an event row inside the same transaction as the state change and relays it asynchronously, producing business-meaningful events at the cost of touching the application. A façade service in front of the legacy API can publish events for the operations it mediates, which works well when writes already flow through a single path.
- Change data capture: zero application change, low semantic value.
- Outbox: business-meaningful events, requires code access.
- Write façade: good fit when all writes share one entry point.
Contracts and schema governance
Events published from a legacy core become long-lived contracts. Register schemas centrally, enforce backward-compatible evolution, and version explicitly when a breaking change is unavoidable. Publish domain events named for what happened in the business — PolicyRenewed, ShipmentDispatched — rather than table names, even when change data capture is the underlying mechanism; a translation step converts row deltas into domain language before anything downstream subscribes.
Delivery semantics consumers can live with
Assume at-least-once delivery and design consumers to be idempotent using event identifiers or natural keys. Where ordering matters, partition by aggregate identifier rather than trying to order the whole stream. Provide a replay capability from the earliest retained offset so a new consumer can rebuild state without asking the legacy team for an extract, and set retention against the slowest realistic recovery scenario.
Operate the backbone as a product
Consumer lag, dead-letter volume, schema-registry rejections, and end-to-end latency belong on a single dashboard with named owners. Dead-letter queues need a documented reprocessing procedure, not just an alert. Treating the event platform as shared infrastructure with a product owner is what keeps it useful once the first integration is live and five more teams want on.
Key takeaways
- Pick the extraction mechanism by how much application access you have.
- Translate row changes into business-named domain events.
- Design every consumer for at-least-once, idempotent processing.
- Partition by aggregate key when ordering matters.
- Monitor lag, dead letters, and schema rejections with named owners.
Talk to NovaHire IT Solutions
Our architects work with enterprise teams on modernization, cloud governance, and platform delivery programmes. Share your scope and a senior engineer will respond.
Start a conversation