DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
This KIP will benefit CEP-44: Kafka integration for Cassandra CDC using Sidecar
Public Interfaces
1. New Producer/Consumer configs to support Composable Serializer/Deserializer
In some use-cases we might need a way to be able to chain of Kafka serializer/deserializer before applying large message serializer for example need to apply schema or special format like avro or protobuf. We could just create a single LargeMessageSerializer org.apache.kafka.common.serialization.largemessage.Serializer that implemented the Kafka Serializer interface, but we would need to create the different versions (AvroSerializer, ProtobufSerializer) with their support for the schema.
Instead the KIP proposing a composable serializer , that still implements the Kafka Serializer interface, but allows concatenating several serializers to perform what we are looking for here.
...
This will be enabled by new configs in Producer/Consumer side
2. org.apache.kafka.common.serialization.largemessage.Serializer
A configurable Kafka serializer that:
- Check if the estimated size of the data (bytes) after applying provided compression (if there is one) it needs needs to serialize is larger than the configured threshold.
- If it is large than the provided threshold (`
large.message.threshold.bytes`):- Use the provided PayloadStore implementation to publish the large message into payload store, generating an id which is the reference to access this later.Encapsulate that ID into a simple Kafka event using a structured format.
- Pass the payload Id as new Kafka Event down to Kafka
- Add a
large-message: trueheader
- If it’s not large then provided threshold (
large.message.threshold.bytes):- Do nothing, pass the data as it is.
- If it is large than the provided threshold (`
3
...
.org.apache.kafka.common.serialization.largemessage.Deserializer
A configurable Kafka deserializer that performs:
- Check if the event is large message by looking for
large-message: trueheader- If it does have `
large-message` header:- Parse the event and retrieve the ID and the needed useful information on the event.
- Use the provided PayloadStore implementation to download the original data from the payload-store.
- Return payload as the final value
- If it doesn't have the
large-messageheader:- Do nothing return the Kafka message as it is
- If it does have `
Proposed Changes
1.
...
New ProducerConfig to support Composable Serializer
Configuration
| Key | Description | Type | Default | Required |
| value.serializers | List of serializers class that implements the `org.apache.kafka.common.serialization.Serializer` interface in order. The first serializer is `Serializer<T>` while the remaining serializers must be `Serializer<byte[]>`. |
Can't be configured with value.serializer at the same time. | List<Serializer> | None | No, If not exist the code will fail back to value.serializer. Can't exist with value.serializer |
| key.serializers | List of serializers class that implements the `org.apache.kafka.common.serialization. |
| Serializer` interface in order. The |
| first serializer is `Serializer<T>` while the |
| remaining serializers must be |
`Serializer<byte[]>`. Can't be configured with key.serializer at the same time. | List<Serializer> | None |
No, If not exist the code will fail back to key.serializer. Can't exist with key.serializer |
2.
...
New ConsumerConfig to support Composable Deserializer
Configuration
| Key | Description | Type | Default | Required |
large.message.payload.store.class| value.deserializers | List of deserializer classes that implements the `org |
| .apache.kafka.common.serialization. |
large.message.payload.store.timeout.msmax.block.msfor Kafka producers ormax.poll.interval.msin Kafka consumer. This is a part of basic configurations for any implementation of org.apache.kafka.common.serialization.largemessage.store.PayloadStorelarge.message.payload.store.retry.countDeserializer` interface in order. The last deserializer must be `Deserializer<T>` while the rest must be `Deserializer<byte[]>`. Can't be configured with value.deserializer at the same time. | List<Deserialzer> | None | No, If not exist the code will fail back to value.deserializer. Can't exist with value.deserializer | |
| key.deserializers | List of deserializer classes that implements the `org.apache.kafka.common.serialization.Deserializer` interface in order. The last deserializer must be `Deserializer<T>` while the rest must be `Deserializer<byte[]>`. Can't be configured with key.deserializer at the same time. | List<Deserialzer> | None | No, If not exist the code will fail back to key.deserializer. Can't exist with key.deserializer |
3. org.apache.kafka.common.serialization.largemessage.Serializer<byte[]>
Configuration
| 5 | No | |||
| Key | Description | Type | Default | Required |
|---|---|---|---|---|
large.message.payload.store. | ||||
class | Implementation of org.apache.kafka.common.serialization.largemessage. | |||
PayloadStore . | ||||
| Class | ||||
| None | ||||
| Yes | ||||
large.message. | ||||
threshold.bytes | The | Delay time between retries back off for payload store operations. This is a part of basic configurations for any implementation of org.apache.kafka.common.serialization.largemessage.store.PayloadStore | 100 | No | large.message.threshold.bytes | The
| maximum size of the message is considered large. | Long | 1MB (Default of max.message.bytes) | No |
...
4.org.apache.kafka.common.serialization.largemessage.Deserializer<byte[]>
Configuration
| Key | Description | Type | Default | Required |
|---|---|---|---|---|
large.message.payload.store.class | Implementation of org.apache.kafka.common.serialization.largemessage | |||
.PayloadStore . | Class | None | Yes |
5.
...
org.
...
apache.
...
kafka.
...
common.serialization.largemessage.PayloadStore
| Code Block | ||
|---|---|---|
| ||
/**
* An interface for publishing and downloading serialised data to/from payload store.
* The store config will passed down from the original config of the Kafka producer/consumer client.
*/
public interface PayloadStore implements Configurable, Closeable {
/**
* Publish data into the store.
*
* @param data data that will be published to the store.
* @return full path to object in the store.
* @throw PayloadStoreException in case failed to publish to the store.
*/
String publish(String topic, byte[] data) throw PayloadStoreException;
/**
* Download full data from the store.
*
* @param fullPath of the data's reference in the store for example `remote_store/topic_name/<record_random_uuid>`
* @return content of the object as bytes.
* @throw PayloadStoreException
*/
byte[] download(String fullPath) throw PayloadStoreException;
/**
* Generate an id for the data's reference in the store (Not the full path in the store).
* By default the id is a random UUID however some stores might need more smarter way to calculate
* its reference id based on the data itself. In such a case please override this method.
* @param data data that will be published to the store.
* @return object id as string, the default implementation support UTF-8 encoding. If any other encoding is required the
* implementation will need to address this.
default String id(byte[] data) {
return java.util.UUID.randomUUID().toString(); // Java UUID is already composed entirely of ASCII characters which are valid UTF-8
}
} |
6. org.apache.kafka.common.serialization.largemessage.PayloadStoreException
| Code Block |
|---|
/**
* Exception class that represent exceptions during interaction with the store.
* this helps the Payload store to decided either to retry or to crash.
* The final Serializer and Deserializer will propagate this as SerializationException to client.
**/
public class PayloadStoreException extends RuntimeException {
/**
* Constructor PayloadStoreException with message and throwable.
*/
public PayloadStoreException(String message, Throwable t) {
super(message, t);
}
/**
* Constructor PayloadStoreException with message |
4. PayloadStore
| Code Block | ||
|---|---|---|
| ||
/** * The contract for any PayloadStore implementation. * This parent abstract class will validate the initial configurations that any payload store must have, like large.message.payload.store.timeout.ms, large.message.payload.store.retry.count, large.message.payload.store.retry.max.backoff.ms and large.message.payload.store.retry.delay.backoff.ms. * And extract them from the provided configs. */ public abstract class PayloadStore implements Configurable, Closeable { Integer maxRetries; Integer timeoutMs; Long maxBackoffMs; Long delayBackoffMs; protected Metrics metrics; @Override public void configure(Map<String, ?> configs) { // configure } /** * Publish data into the store. * * @param data data that will be published to the store. * @return {@link PayloadResponse}. */ public abstract PayloadResponse publish(String topic, byte[] data); /** * Download full data from the store. * * @param path id of the data's reference in the store * @return content of the object as bytes. */ public abstract byte[] downloadPayloadStoreException(String pathmessage); { /** * Generate an id for the data's reference in the store. super(message); } /** * ByConstructor defaultPayloadStoreException thewith idthrowable. is a random UUID however*/ some stores might needpublic more smarter way to calculate its reference id. PayloadStoreException(Throwable t) { * In such a case please override this method. * @param data data that will be published to the store. public String id(byte[] data) { return UUID.randomUUID().toString(); } } |
6. PayloadReferenceValue
| Code Block |
|---|
/** PayloadReferenceValue represent the final published payload reference into Kafka.
* It includes the full payload path on the store as well as the store class used for the publishing.
* This allow the deserializer to throw a more informative errors if the original payload store class doesn't match the one setup by the consumer client.
*/
{
"apiKey": 0,
"type": "payload-reference",
"name": "PayloadReferenceValue",
// Version 0 KIP-1159.
"validVersions": "0",
"fields": [
{ "name": "fullPayloadPath", "versions": "0+", "type": "string", "about": "The full path to access payload as string."},
{ "name": "payloadStoreClass", "versions": "0+", "type": "string","about": "The used payload store class path to upload payload."}
]
}
|
7. PayloadResponse
| Code Block | ||
|---|---|---|
| ||
/**
* Response from publish / download from PayloadStore back to the serialization layer
* It contains the final path, response code and the encountered exception if there was any.
*/
public class PayloadResponse {
public final int responseCode;
public final String path;
public final PayloadStoreException PayloadStoreException;
/**
* Construct payload response with response code and payload id.
*/
public PayloadResponse(int responseCode, String path) {
this(responseCode, path, null);
}
/**
* Construct payload response with response code, payload id and exception.
*/
public PayloadResponse(int responseCode, String path, PayloadStoreException payloadStoreException) {
this.responseCode = responseCode;
this.fullPayloadPath = path;
this.PayloadStoreException = payloadStoreException;
}
} |
Example
...
| language | java |
|---|
...
super(t);
}
}
|
Example
Producer
| Code Block | ||
|---|---|---|
| ||
Map<String, Object> producerConfig = new HashMap<>();
producerConfig.put("value.serializers", "kafka.serializers.KafkaAvroDeserializer, org.apache.kafka.common.serialization.largemessage.Serializer");
producerConfig.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); producerConfig.put("large.message.payload.store.class", "myclient.payloadstore.CustomS3Store")
producerConfig.put("large.message.threshold.bytes", 1048576);
producerConfig.put("s3.bucket", "my-bucket")
producerConfig.put("s3.retry.attempts", "3");
producerConfig.put("s3.connection.timeout.ms", "5000");
producerConfig.put("bootstrap.servers", "localhost:9092");
KafkaProducer<String, byte[]> producer = new KafkaProducer<>(producerConfig); |
Consumer
| Code Block | ||
|---|---|---|
| ||
Map<String, Object> consumerConfig = new HashMap<>();
producerConfig.put("value.deserializers", "org.apache.kafka.common.serialization.largemessage.Serializer, kafka.serializers.KafkaAvroDeserializer");
consumerConfig.put("key.deserializer", "org.apache.kafka.common.serialization.StringSerializer"); consumerConfig.put("large.message.payload.store.class", "myclient.payloadstore.CustomS3Store")
consumerConfig.put("s3.bucket", "my-bucket")
consumerConfig.put("s3.retry.attempts", "3");
consumerConfig.put("s3.connection.timeout.ms", "5000");
consumerConfig.put("bootstrap.servers", "localhost:9092");
KafkaConsumer<String, Object> consumer = new KafkaConsumer<>(consumerConfig); |
Considerations
TTL Configuration Risk: If the payload store owner doesn't configure an appropriate TTL that aligns with Kafka topic retention, the payload store may grow indefinitely. This occurs because objects remain in storage even after Kafka no longer references them, leading to unnecessary storage costs.
TTL Too Short Risk: If the TTL is set too aggressively (shorter than needed), Kafka references may point to objects that no longer exist in the payload store. When this happens:
Consumers will encounter NOT_FOUND errors
To prevent blocking behavior, consumers should capture SerializationException::getCause and decide what to do if the exception is PayloadException/PayloadNotFoundException.
This allows graceful handling of missing payload references
- TTL and usage of Compacted Topic: for applications that do use compacted topics with large payloads, the PayloadStore implementation should handle this by:
Consistent ID Generation:PayloadStore implementations should use deterministic IDs based on message content or metadata (rather than random UUIDs) so that identical payloads can reuse the same storage object, reducing storage costs.
TTL Strategy:
Since compacted topics can retain data indefinitely, users must accept the indefinite storage costs that comes with this case. If cost is an issue they will need to setup a cleanup job that observer Kafka key with null value and delete the associated payload with this key.
Topics with
cleanup.policy=compact,deletewill eventually remove old data, so standard TTL approaches work normally.
Recommendation: Set TTL duration to exceed your Kafka topic retention period by a reasonable buffer (e.g., 10-20%) to ensure payload availability throughout the message lifecycle while preventing indefinite storage growth.
- Partial Failure Handling: If payload storage succeeds but Kafka produce fails, the payload will remain in storage until TTL expires. This is acceptable as it only affects storage costs, not correctness. If Kafka message is consumed but payload download fails, the client can capture SerializationException::getCause and determine behavior.
Critical Timing Constraints: The total timeout for payload store operations (including all retries) cannot exceed `max.block.ms` for Kafka producers or `max.poll.interval.ms` for Kafka consumers. This is a fundamental requirement for any implementation of org.apache.kafka.common.serialization.
...
largemessage.PayloadStore.
Exceeding these limits will cause producer blocking or consumer rebalancing issues.
Memory Constrains: Large messages will consume memory during serialization so ensure heap size can accommodate your largest expected message. ConsiderPayloadStoreimplementationsthatsupportcompressiontoreducestoragefootprint.
Compatibility, Deprecation, and Migration Plan
- Old clients just need to set the needed configuration to use this feature
Rejected Alternatives
- We have rejected implementing the chunking pattern due to its many potential edge cases and complexity added to the consumer side. A peak of those complexities can be explored more deeply in the LinkedIn presentation.
- Implement this as a separate project outside of Apache Kafka as this seems to be a pattern that needs more use cases and it would be better to have this in Apache Kafka as native implementation instead of a separate project
- Implement the AsyncPayloadStore: Thisdoesn'tprovideanybenefitsinceKafka'sSerializerinterfaceissynchronous/blocking-anyasyncoperationswouldneedtoimmediatelycall.get(),negatingtheasyncbenefits. Also the reality is that most of use-cases that needs more > 1MB messages:
Are dealing with bulk data (collections, arrays)
Can afford the memory cost during brief serialization
Run on appropriately sized JVMs
Usecases with truly memory-constrained environments probably shouldn't be sending GB-sized messages through Kafka anyway.
Compatibility, Deprecation, and Migration Plan
- Old clients just need to set the needed configuration to use this feature
Rejected Alternatives
...