...

• Current client users should not be affected, this is new api methods being added to client apis
• Message version allows clients expecting older message version, would not be impacted 
  • older producers simply would produce a message without headers
    • new consumer would simply get a message with empty headers
  • older consumers simply would consume a message oblivious to there being any headers
• Message version migration would be handled as like in KIP-32

Out of Scope

Some additional features/benefits were noticed and discussed on the above but are deemed out of scope and should be tackled by further KIPS.

• Core message size reduction
  • remove overhead of 4 bytes for KeyLength when no headers using attributes bit
  • reduce overhead of 4 bytes for KeyLength by using variable length encoded int
  • reduce overhead of 4 bytes for ValueLength by using variable length encoded int
• Broker side interceptors
  
  • with headers we could start introducing broker side message interceptors to append meta data or handle messages
• Single Record consumer API
  • There is many uses cases where single record consumer/listener api is more user friendly - this is evident by the fact spring kafka have already created a wrapper, it would be good to support this natively.

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.

...