Page History

• Adds the ability for producers to set standard header key=value value pairs
• No incompatible client api change (only new methods)
• Allows users to specify the serialisation of the header value per header
• Provides a standardised interface to eco systems of tools that then can grow around the feature

The disadvantage of this proposal is:

• Change to the message object

Key duplication and ordering

• Duplicate headers with the same key must be supported.
• The order of headers must be retained throughout a record's end-to-end lifetime: from producer to consumer.

Create a Headers Interface and Implementation to encapsulate headers protocol.

• See above public interfaces section for sample interfaces.

Add a headers field Headers to both ProducerRecord and ConsumerRecord

• Accessor methods of Headers headers() added to interface of the ProducerRecord/ConsumerRecord.
• Add constructor(s) of Producer/ConsumerRecord to allow passing in of an existing/pre-constructed headers via Iterable<Header> 
  1. use case is MirrorMakers able to copy headers.

Add new method to make headers accessible during de/serialization

• Add new default method to Serialization/Deserialzation class, with Header parameter
  • Due to KIP-118 not being implemented, a new extended interface ExtendedSerializer ExtendedDeserializer with new extra methods is introduced instead
    • Existing De/Serialization will be wrapped and work as before.