Airbnb CDC & Strangler Migration Lab (Interactive)
Strangler-fig the Monorail while Debezium CDC keeps Elasticsearch honest in 500ms. Carve a 1,000-engineer Rails monolith into gRPC domains behind shadow validation, and stream listing mutations through the binlog to sub-20 ms facet search — or dual-write and count the divergence.
Monorail Strangler & CDC Search Sync Lab
Strangler-fig a 1,000-engineer Rails monolith while Debezium CDC streams listing mutations to Elasticsearch — and watch what dual-writing does to the index.
How It Works Under the Hood
Airbnb's Monorail — one Ruby on Rails app with a four-hour deploy train and one MySQL database — became untenable past 1,000 engineers. The fix was the Strangler Fig pattern: bounded contexts extracted as Java and Kotlin gRPC services behind gateways, validated in shadow mode against monolith responses before any traffic cutover. Search moved off MySQL entirely: Debezium tails the binlog, Kafka's listing_mutations topic carries row changes, and denormalization workers keep Elasticsearch's geo-point, amenity, and calendar-bitset indexes visible to guests within five hundred milliseconds.
Core Architectural Principles
- Dual-write anti-pattern: writing MySQL and Elasticsearch from app code diverges on every dropped second write; CDC replays the committed log instead.
- Strangler cutover pipeline: route shadow traffic, diff responses, then flip bounded contexts one at a time with no big-bang rewrite.
- Search economics: sub-20 ms multi-facet queries require precomputed inverted indexes and availability bitsets, never live SQL scans.
In migration rounds, name the pattern and its guardrails: "Strangler fig behind an API gateway with shadow validation — never a big-bang rewrite." In search rounds, attack dual-writes: "If the second write fails, data diverges permanently; CDC from the WAL guarantees at-least-once sync." Volunteering the 500 ms staleness window as the consistency price scores points.
CDC and strangler migration buy consistency and continuous delivery but accept ~500 ms index staleness and permanent IDL versioning governance.