Evolving Schemas Without Schema Evolution With Andreas Evers | Current 2022
Schema Registry allows us to control how schemas can be evolved through time without breaking compatibility. However, when using high retention, you could end up with a convoluted “dirty” schema depending on the selected compatibility level, as well as many different models in your application logic to support all the schema versions.
Upcaster chains allow you to read an old version of a message and bring it to what your logic needs today. The upcasters in the chain describe how to jump from one version to the next. They describe what your logic expects instead of covering all the possible variations that were ever published.
We created an upcaster registry to allow you to declare upcasters and their chains in a declarative manner allowing them to be used across all your streaming apps. It is a great combo with Schema Registry; one providing the schemas themselves, the other expressing how to evolve from one schema version to the next.
2. Abstract
Schema Registry allows us to control how schemas can be evolved through time without breaking compatibility.
However, when using high retention, you could end up with a convoluted “dirty” schema depending on the selected
compatibility level, as well as many different models in your application logic to support all the schema versions.
Upcaster chains allow you to read an old version of a message and bring it to what your logic needs today.
The upcasters in the chain describe how to jump from one version to the next. They describe what your logic expects instead of
covering all the possible variations that were ever published.
We created an upcaster registry to allow you to declare upcasters and their chains in a declarative manner allowing them to be
used across all your streaming apps. It is a great combo with Schema Registry; one providing the schemas themselves, the other
expressing how to evolve from one schema version to the next.
3. Andreas Evers
CTO @ KOR Financial
Previously Pivotal / VMware
➢ Staff solution architect consulting for some of the biggest European firms
➢ Focused on application transformation & system design
➢ Worked on Spinnaker, together with the Spring team
Who is this guy?
@andreasevers
13. The typical use case offloads the streamed events into an external database
Those databases typically use commit logs or sequential files internally
Such commit logs and sequential files are in fact very similar
to Kafka topics and segment files 🤔
Why not use Kafka as the commit log for your data, and
become the system of record instead of merely a tunnel
14. KSQL: Turning the database inside-out
Source of truth
stream
Continuous
query
Derived table
15. High retention offers a lot of benefits,
but also comes with its own unique challenges
You can’t just wait 7 days
for old formats to leave your cluster
42. Client Functions
Client Stub
Server Functions
Server Stub
(skeleton)
Network Routines Network Routines
kernel
client
process
kernel
server
process
network
client server
43. Client Objects
Client SOAP Handler
Server Objects
Server SOAP Handler
Network Routines Network Routines
network
kernel
client
process
kernel
server
process
client server
46. - Rick
- Morty
- Summer
Class People {
- Rick
- Morty
}
Class People {
- Rick
- Morty
- Summer
}
Be conservative in what you do,
be liberal in what you accept from others.
@JsonIgnoreProperties
(ignoreUnknown = true)
47. - Rick
- Morty
0
Class People {
- Rick
- Morty
}
Class People {
- Rick
- Morty
- Summer
}
- Rick
- Morty
- Summer
1
Be conservative in what you do,
be liberal in what you accept from others.
Tolerant
GenericRecordToDto
Deserializer
72. Schema Evolution through Schema Registry
Schema Registry
• Versions every schema
• Every schema has a unique ID
• Uses subjects with Topic, Record, or TopicRecord names
• For each subject, each schema change gets a version increase
Schema
ID: foo
Schema
ID: bar
Subject
topic-People
- Rick
- Morty
- Rick
- Morty
- Summer
V1
V2
73. Compatibility Types
Compatibility Type Changes allowed Check against which schemas Upgrade first
BACKWARD Delete fields
Add optional fields
Last version Consumers
BACKWARD_TRANSITIVE Delete fields
Add optional fields
All previous versions Consumers
FORWARD Add fields
Delete optional fields
Last version Producers
FORWARD_TRANSITIVE Add fields
Delete optional fields
All previous versions Producers
FULL Add optional fields
Delete optional fields
Last version Any order
FULL_TRANSITIVE
Add optional fields
Delete optional fields
All previous versions Any order
NONE All changes are accepted Compatibility checking disabled Depends
75. Class People {
- Rick
- Optional<Summer>
}
Backward
0 1
- Rick
- Morty
- Rick
- Optional<Summer>
76. Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Optional<Summer>
}
Backward
- Rick
- Morty
0
- Rick
- Optional<Summer>
1
77. Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Optional<Summer>
}
Backward
0 1
- Rick
- Morty
- Rick
- Optional<Summer>
78. Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Optional<Summer>
}
Backward
0 1
- Rick
- Morty
- Rick
- Optional<Summer>
79. Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Optional<Summer>
}
- Rick
- Optional<Summer>
Backward
80. Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Optional<Summer>
}
- Rick
- Optional<Summer>
Backward
81. Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Morty
}
- Rick
- Morty
Backward
82. Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Morty
}
- Rick
- Morty
Backward
83. - Rick
- Morty
0
Class People {
- Rick
- Optional<Summer>
}
- Rick
- Optional<Summer>
1
- Rick
2
Backward
Transitive
84. - Rick
- Morty
0
Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Optional<Summer>
}
- Rick
- Optional<Summer>
1
- Rick
2
Backward
Transitive
85. - Rick
- Morty
0
Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Optional<Summer>
}
- Rick
- Optional<Summer>
1
- Rick
2
Backward
Transitive
86. - Rick
- Morty
0
Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Optional<Summer>
}
- Rick
- Optional<Summer>
1
- Rick
2
Backward
Transitive
87. - Rick
- Morty
0
Class People {
- Rick
- Optional<Summer>
}
Class People {
- Rick
- Optional<Summer>
}
- Rick
- Optional<Summer>
1
- Rick
2
Backward
Transitive
97. - Rick
- Optional<Morty>
0
Class People {
- Rick
- Optional<Morty>
}
Class People {
- Rick
- Summer
}
- Rick
- Summer
1
- Rick
2
Forward
Transitive
98. Short Retention = Full?
Backward when
• you want to allow the producer to roll back to a previous version,
writing a previous schema, without breaking consumers (provided they
are tolerant readers)
Forward when
• you want to allow consumers to read new versions without needing to
be updated first (provided they are tolerant readers and non-compatible
upgrades are controlled, e.g. using CDCT)
99. High Retention = Full Transitive?
Backward transitive when
• you want to allow new consumers which will start at offset 0,
to be added at any time in the future
• or you want to allow producers to roll back to any previous version,
writing a previous schema, without breaking consumers (provided they
are tolerant readers)
Forward transitive when
• you want to allow consumers to read new versions without needing to
be updated first (provided they are tolerant readers)
regardless from where they start consuming
100. High Retention = Full Transitive forever?
Class People {
- Optional<Rick>
- Optional<Morty>
- Optional<Summer>
- Optional<PickleRick>
- Optional<Rick:boolean>
}
157. Combining strategies for short retention
• Versioned Events
• Tolerant Reader
• Consumer-driven Contract Testing
158. Combining strategies for short retention
This allows you to:
• Avoid transitive
• Avoid the optional dance
• Chase consumers to upgrade
• Prevent producers from mistakenly releasing incompatible version
after releasing compatible version
• Keep your consumers tolerant to change
• Keep your consumers ignorant of information they don’t need
159. Combining strategies for high retention
• Versioned Events
• Upcasting
• Upcaster registry
• Tolerant Reader
• Copy-Transform
160. Combining strategies for high retention
This allows you to:
• Avoid Full Transitive Forever
• Avoid every field being optional
• Avoid having to write to countless deprecated fields
• Keep your consumers tolerant to change
• Keep your consumers ignorant of information they don’t need
161. Thank you!
Accreditations:
Graphics by Arthur Shlain, Creative Stal, Siddharth Dasari, Webtechops LLP, Icons Producer, SBTS from Noun Project
Andreas Evers
@andreasevers
aevers@korfinancial.com
KOR Financial
www.korfinancial.com