Relevant data
Background
Avro schemas will be used to document APIs and their changes in our Kafka topic to facilitate communication between our microservices. The Avro schemas will be used to generate the code that will be used to produce and consume Kafka messages in the services. This decision is about how we’re managing these schemas and their changes.
Options considered
Avro schemas in a single project | Separate project for every schema | |
---|---|---|
Description | Every version of every Avro schema lives in a single project and can be used by referencing a single artifact as a dependency. | Every Avro schema has it’s own project and published as a separate artifact, Consumers reference only the version of the schemas they are consuming directly. |
Pros and cons | Having a single artifact for all the schemas makes development easier Having more than one version of the same schema on the classpath Release of new artifact versions are coupled | Clear dependency declaration for every consumed schema with exact version Independent versioning for every schema More automation is needed to make the creation of new schema projects easy |
Estimated cost | LOW | MEDIUM |
Action items
Outcome
We’ll use a common project for every Avro schema we’re using. We’ll ship every schema in a single artifact which the microservices can depend on. More details are under the Kafka topic schema management page