How to Evolve your Microservice Schemas | Designing Event-Driven Microservices

Schema evolution is the act of modifying the structure of the data in our application, without impacting clients. This can be a challenging problem. However, it gets easier if we start with a flexible data format and take steps to avoid unnecessary data coupling. When we find ourselves having to make breaking changes, we can always fall back to creating new versions of our APIs and events to accommodate those changes.

RELATED RESOURCES

CHAPTERS
00:00 - Intro
00:16 - What is a schema?
00:45 - Do schemaless formats need to evolve?
01:22 - What is schema evolution?
02:06 - How does the data format impact schema evolution?
02:37 - What is a forward-compatible schema?
03:01 - What is a backward-compatible schema?
03:40 - How do we version our APIs and Events?
04:15 - Should my APIs use shared libraries?
05:23 - How can I advertise my schema changes?
05:52 - Closing

--

ABOUT CONFLUENT

#microservices #apachekafka #kafka #confluent

[sarwan.surchi]

Thanks Wade for the video. mentioning protobuf with such capabilities, I am very curious to check it out and see how it eliminates coupling.

[marcialabrahantes]

Curious what did you imply by "protobuf is not human readable like JSON" in the context of renaming a field ?

Per my experience any renames in Protobufs will be a breaking change as all your clients will need to be updated. so most changes are made to be backwards compatible by what you mentioned (new field, existing field gets ignored going forward).

So I'm not sure what is the contrasting argument.

[nnz]

Schema microservice for microservices 😂