0

What is the downside of handling a breaking contract change, which can adversely affect some of the consumers on the same pipeline [i.e. producer, topic, consumer tuple], through different topic altogether? Or use a flattened Object structure that comprises of both old/new fields? We are using Spring-Boot.

In the context of changes to be done, why wouldn't we do it compared to using Schema Registry?

OneCricketeer
  • 179,855
  • 19
  • 132
  • 245
Divs
  • 1,578
  • 2
  • 24
  • 51

1 Answers1

0

Well, by default, the Schema Registry enforces Backwards Schema Evolution, so there couldn't be a truly breaking schema change until you explicitly set the subject configuration to not perform compatibility checking at all.

If you absoultely need to break the schema, you could delete a subject in the registry (but this won't delete existing Avro ID's for that data in the topic)

If you flatten the data, I don't see the difference in that with CSV... Having all fields available at the top-level of the message doesn't change the fact you might need to remove or add fields that later need parsed.

The Schema Registry can use different types within a single topic, if you did need it to.

OneCricketeer
  • 179,855
  • 19
  • 132
  • 245
  • Argument in favor of flattened structure can be, the fields can be removed when there are no consumers of those fields. Also, to my other question, what would be downside of handling new traffic with new schema with a new topic and creating producer,consumer from/to the topic; – Divs Nov 29 '18 at 04:38