Status

Current state: Under Discussion

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: here [Change the link from KAFKA-1 to your own ticket]

Motivation

Kafka TopicPartitions are replicated on the broker side to different racks. KIP-881 added rack information of clients in partition assignment interface so that the assignment logic can utilize this information to try to assign TopicPartitions to the clients in the same rack as much as possible. The reason why we would like to place TopicPartions to clients in the same rack is because this would avoid cross rack traffic (CRF) which has high costs in terms of latency and money.

The client rack awareness additions in partition assignments also affects how streams can assign its tasks to clients so that cross rack traffic can be avoided as much as possible if partition replicas’ racks won’t always be presented in the client's rack. This design discusses how we can augment current assignment logic to utilize rack information to minimize cross rack traffic with other constraints. In CCloud, currently each partition is replicated to 3 replicas in different AZs, however it’s being changed to replicate to only 2 AZs and other storage like S3 which is where the 2.5x is from.

Public Interfaces

There are no changes in public interfaces.

Proposed Changes

Describe the new thing you want to do in appropriate detail. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences. Use judgement based on the scope of the change.

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
• If we are changing behavior how will we phase out the older behavior?
• If we need special migration tools, describe them here.
• When will we remove the existing behavior?

Test Plan

Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

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.