@gunnarmorling @hpgrahsl
● Open source software engineer at Red Hat
○ Debezium
○ Quarkus
● Spec Lead for Bean Validation 2.0
● Java Champion
Gunnar Morling
Slide 5
Slide 5 text
@gunnarmorling @hpgrahsl
system migrations
are challenging
@hpgrahsl
Slide 6
Slide 6 text
@gunnarmorling @hpgrahsl
hard cut-overs
are very risky
@gunnarmorling
Slide 7
Slide 7 text
@gunnarmorling @hpgrahsl
BIG BANG
migrations often
doomed to failure
@hpgrahsl
Slide 8
Slide 8 text
@gunnarmorling @hpgrahsl
strangler fig
pattern to
the rescue
@gunnarmorling
@gunnarmorling @hpgrahsl
System Migration Goal
● gradually evolve from old into new
● support temporary coexistence
● avoid big bang cut-over
@hpgrahsl
Slide 11
Slide 11 text
@gunnarmorling @hpgrahsl
Open-Source Change-Data-Capture With Debezium
● Captures INSERT/UPDATE/DELETE events by tapping into DB’s TX log
● Changes propagated via Apache Kafka & Kafka Connect
Slide 12
Slide 12 text
@gunnarmorling @hpgrahsl
Debezium in a Nutshell
● Feature-rich CDC Platform
○ Based on transaction logs
○ Snapshotting, filtering, etc.
○ Outbox support
○ Web-based UI
● Very active OSS community
● Large production deployments
@gunnarmorling @hpgrahsl
Debezium – Data Change Events
● Message Key: table PK
● Message Value:
○ Old and new row state
○ Metadata on table, TX id, etc.
○ Operation type, timestamp
● Serialized as JSON, Avro, etc.
Slide 16
Slide 16 text
@gunnarmorling @hpgrahsl
Debezium – Data Change Events
● Message Key: table PK
● Message Value:
○ Old and new row state
○ Metadata on table, TX id, etc.
○ Operation type, timestamp
● Serialized as JSON, Avro, etc.
Slide 17
Slide 17 text
@gunnarmorling @hpgrahsl
● Message Key: table PK
● Message Value:
○ Old and new row state
○ Metadata on table, TX id, etc.
○ Operation type, timestamp
● Serialized as JSON, Avro, etc.
Debezium – Data Change Events
@gunnarmorling @hpgrahsl
CDC Pipeline Considerations
● data model leaking from monolith ?
● “1:1 replication” → building aggregates ?
● transactional boundaries in the monolith ?
@hpgrahsl