I'm convinced by the principle of reducing inter-zone cloud costs for Apache Kafka. There are still a lot of missing details in 1163 and 1164, but this foundational KIP looks good to me.
+1 (binding) Thanks, Andrew On 2026/02/25 16:32:27 Greg Harris via dev wrote: > Hey all, > > I'm excited to discuss more details in 1163 and 1164 with everyone. > > +1 (binding) > > Thanks! > Greg > > On Wed, Feb 25, 2026 at 1:08 AM Anatolii Popov via dev <[email protected]> > wrote: > > > Hi all, > > > > Given the importance of this KIP, we want to keep the vote open for a few > > more days to give time to people who had comments in the DISCUSS thread to > > cast their vote if they want. > > > > On Wed, Feb 25, 2026 at 10:47 AM Josep Prat via dev <[email protected]> > > wrote: > > > > > Hi all, > > > As a co-author of the KIP, I want to explicitly cast my vote for this > > KIP. > > > > > > +1 (binding) > > > > > > > > > On Wed, Feb 25, 2026 at 9:02 AM Luke Chen <[email protected]> wrote: > > > > > > > I've re-read KIP-1150, and still agree this is what we need for Apache > > > > Kafka. > > > > > > > > +1 (binding) from me. > > > > > > > > Thank you, > > > > Luke > > > > > > > > On Wed, Feb 25, 2026 at 12:10 PM Chris Egerton < > > [email protected]> > > > > wrote: > > > > > > > >> Hi all, > > > >> > > > >> Thanks for the KIP. I've reviewed 1150, 1163, and 1164, as well as the > > > >> relevant discussion threads. I may have granular comments about 1163 > > and > > > >> 1164 but the overall approach suggested in 1150 looks good to me. I > > > >> especially like that the approach covers two main pain points of > > > operating > > > >> and paying for Kafka today: it allows cross-AZ traffic to be reduced > > > (even > > > >> eliminated in some cases), and it also allows local disk usage by > > > brokers > > > >> to be reduced (if operators opt for a small local cache on follower > > > >> brokers > > > >> for non-tiered segments). > > > >> > > > >> +1 (binding) > > > >> > > > >> Cheers, > > > >> > > > >> Chris > > > >> > > > >> On Mon, Jan 26, 2026 at 3:36 PM vaquar khan <[email protected]> > > > >> wrote: > > > >> > > > >> > Hi Josep, > > > >> > > > > >> > Thank you for the detailed response. I appreciate the clarification > > > >> > regarding the distinction between the Inkless POC and the KIP > > design. > > > >> > > > > >> > However, my objection is not based on temporary bugs in the fork, > > but > > > >> *on > > > >> > architectural gaps in the KIPs themselves* that these implementation > > > >> issues > > > >> > highlighted. If we are voting to approve the design, the design > > > >> documents > > > >> > must be structurally complete regarding data safety. > > > >> > > > > >> > *1. Regarding Storage Leaks (The Missing Design)* You mentioned that > > > >> > cleanup logic "can be defined later." However, KIP-1163 explicitly > > > >> > delegates this responsibility to a separate process, and KIP-1165 > > > >> (Object > > > >> > Compaction/GC) is currently marked as "Discarded" in the wiki. > > > >> > > > > >> > We cannot vote to approve a storage engine that has no specified > > > >> mechanism > > > >> > for garbage collection. The "Upload-then-Commit" pattern described > > in > > > >> > KIP-1163 structurally creates orphaned segments during broker > > > failures. > > > >> > Without an active KIP defining the reconciliation protocol (since > > > >> KIP-1165 > > > >> > was withdrawn), the proposal effectively describes a system with > > > >> unbounded > > > >> > storage growth during failure modes. This is a blocking design gap, > > > not > > > >> an > > > >> > implementation detail. > > > >> > > > > >> > *2. Regarding EOS (The Coordinator Synchronization Gap)* This is > > not a > > > >> > misunderstanding of standard Kafka transactions; it is a critique of > > > how > > > >> > KIP-1150 changes them. Standard EOS relies on the Partition Leader > > to > > > >> > sequence markers and calculate the LSO (Last Stable Offset) in > > memory. > > > >> > KIP-1150 removes the Leader. > > > >> > > > > >> > KIP-1164 (Batch Coordinator) must explicitly define the RPC flow > > > between > > > >> > the Transaction Coordinator and the Batch Coordinator to replace the > > > >> > leader's role. Currently, the KIP does not specify how the system > > > >> prevents > > > >> > a "Split Brain" scenario where a consumer reads ahead of a > > transaction > > > >> > marker that hasn't yet been sequenced by the Batch Coordinator. This > > > is > > > >> a > > > >> > protocol-level correctness issue that must be resolved in the text > > > >> before > > > >> > adoption. > > > >> > > > > >> > Please note - I am maintaining my objection based on missing > > > >> > specifications, not code bugs. > > > >> > > > > >> > I respectfully request that we pause the vote until: > > > >> > > > > >> > A valid design for Garbage Collection (replacing the discarded > > > >> > KIP-1165) is added to the proposal. > > > >> > > > > >> > The Transaction/LSO synchronization protocol is explicitly > > > >> documented > > > >> > in KIP-1164. > > > >> > > > > >> > Regards, > > > >> > > > > >> > Vaquar Khan > > > >> > Sr Data Architect > > > >> > https://www.linkedin.com/in/vaquar-khan-b695577/ > > > >> > > > > >> > > > > > > > > > > -- > > > [image: Aiven] <https://www.aiven.io> > > > > > > *Josep Prat* > > > Sr. Engineering Director, Streaming Services, *Aiven* > > > [email protected] | +491715557497 > > > aiven.io <https://www.aiven.io> | < > > https://www.facebook.com/aivencloud > > > > > > > <https://www.linkedin.com/company/aiven/> < > > > https://twitter.com/aiven_io> > > > *Aiven Deutschland GmbH* > > > Alexanderufer 3-7, 10117 Berlin > > > > > > Geschäftsführer: Oskari Saarenmaa, Kenneth Chen > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > -- > > Anatolii Popov > > Senior Software Developer, *Aiven OY* > > m: +358505126242 > > w: aiven.io e: [email protected] > > <https://www.facebook.com/aivencloud> > > <https://www.linkedin.com/company/aiven/> <https://twitter.com/aiven_io> > > >
