RealtyMogul · Engineering case study
Two systems, one moving set of records
Moving live records from a legacy platform toward newer services without treating migration as a one-time copy.
At RealtyMogul, the older Drupal platform and newer services had to coexist. Investment and account records kept changing while the destination was being built. I worked on the event bridge and the checks around bulk movement.
The problem
A migration has two clocks: the initial backfill and the next change a person makes. If those paths are hard to distinguish, a record can look current while the systems disagree.
The bridge also had to process many event types without letting one busy queue overwhelm the downstream work or make failures impossible to trace.
What I did
Treat changes as events
Worked on object-specific processors for live legacy updates, including investment-related fields, and carried origin metadata so downstream handlers could see where an update began.
Give bulk movement a checkable path
Added verification tooling for bulk synchronization and worked on handlers used to move sets of records, rather than assuming that a job starting meant it had finished correctly.
Bound the work
Limited queue consumer concurrency and kept event routing explicit, making the bridge easier to reason about when live updates and backfills overlapped.
What changed
The bridge had separate paths for live changes and backfills, with provenance and verification to help investigate discrepancies. I contributed to this migration over time; the wider platform and its data ownership were shared across the team.