Glue Services: Part Two — Data Synchronization.
I recently talked about using glue services (Anti-Corruption Layers) to isolate modern platforms from legacy integrations.
Today I want to talk about another type of glue service: data synchronization services.
🗃️ The Real Modernization Problem
One of the hardest parts of replacing a legacy platform is usually not the application itself.
It’s the data.
In a perfect world, you could: take downtime, export the database, import it into the new platform, and switch traffic.
Simple.
But large downtime windows are increasingly rare. And big-bang migrations are risky enough that many organizations actively avoid them.
That means old and new systems often need to run side-by-side for a while.
Both platforms stay active.
Both serve customers.
Both need access to the same data. This is where modernization becomes difficult.
🔄 Keeping Two Systems in Sync
When you are changing both the application and the underlying database, keeping data synchronized becomes difficult very quickly.
Especially when the two systems use different schemas, database technologies, data models, and update patterns.
You can’t simply export/import anymore. You need continuous synchronization.
👨🏻🤝👨🏾 Enter the Synchronization Service
One useful pattern is to build a dedicated synchronization service whose sole responsibility is to keep data aligned across systems.
How synchronization works depends entirely on the platform.
I’ve used several approaches over the years.
⚙️ Database Triggers
One approach is to use database triggers or change-capture mechanisms in the legacy system.
When data changes, it’s detected, the synchronization service processes it, and the new platform is updated.
📩 Event-Based Synchronization
Another approach is to have the legacy platform emit events via a message broker.
The synchronization service consumes those events and updates the new database/platform accordingly. This tends to work especially well when modernizing toward event-driven systems.
⏳ Temporary Infrastructure
The important thing to remember is that these synchronization services are usually temporary. Their job is not to become a permanent platform.
Their purpose is to enable safe migration while reducing downtime and risk.
Once the migration is complete, the glue service disappears.
⚠️ One Important Warning
Bi-directional synchronization becomes extremely difficult very quickly.
With bi-directional synchronization, you have to solve:
- Conflict resolution
- Consistency problems
- Update ordering
- Partial failures
Whenever possible, avoid bi-directional synchronization.
In many cases, it is simpler to migrate the application layer first, then the database layer.
🧐 Final Thought
Modernization is rarely just replacing code. A major challenge is safely bridging old and new systems during transition periods.
Synchronization glue services are often what make zero-downtime migrations possible.