Producer Internal Architecture
Thread Model and Data Flow
The Kafka producer operates with a sophisticated multi-threaded architecture designed for high throughput and reliability:
APPLICATION THREAD BACKGROUND SENDER THREAD
│ │
▼ │
┌─────────────┐ │
│ send() API │ │
└──────┬──────┘ │
│ │
▼ │
┌─────────────┐ │
│ Serializer │ │
│ (Key/Value) │ │
└──────┬──────┘ │
│ │
▼ │
┌─────────────┐ │
│ Partitioner │ │
│(Hash/Custom)│ │
└──────┬──────┘ │
│ │
▼ ▼
┌──────────────────────────────────────────────────────┐
│ RecordAccumulator │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Batch P0 │ │ Batch P1 │ │ Batch P2 │ ... │
│ └────────────┘ └────────────┘ └────────────┘ │
└──────────────────────────┬───────────────────────────┘
│
▼
┌─────────────────────┐
│ Sender Thread │
│ ┌───────────────┐ │
│ │ NetworkClient │ │
│ └───────────────┘ │
└──────────┬──────────┘
│
▼
TO BROKERS
Key Components Breakdown
RecordAccumulator:
- Manages per-partition buffers
- Handles batching and memory allocation
- Thread-safe operations for producer API calls
- Memory pool management for efficiency
// Buffer memory allocation
buffer.memory=67108864 // 64MB total
batch.size=32768 // 32KB per batchSender Thread:
- Single background thread per producer instance
- Manages network I/O to brokers
- Handles response processing and retries
- Maintains connection pools and metadata
Network Client:
- Manages TCP connections to brokers
- Request/response correlation
- Connection state management
- Handles broker discovery and metadata refresh
Memory Management Deep Dive
Total Buffer Memory: 64MB (default) ├── Free Memory Pool ├── Batch Buffers (per partition) ├── Incomplete Batches └── Available Memory Tracking Memory Pressure Handling: ├── Block send() calls when full ├── Configurable timeout (max.block.ms) ├── Memory reclamation on batch completion └── GC-friendly buffer reuse
Production Memory Configuration:
Properties props = new Properties();
// Total memory for buffering
props.put(ProducerConfig.BUFFER_MEMORY_CONFIG, 134217728); // 128MB
// Batch size per partition
props.put(ProducerConfig.BATCH_SIZE_CONFIG, 65536); // 64KB
// Block time when buffer full
props.put(ProducerConfig.MAX_BLOCK_MS_CONFIG, 60000); // 60 seconds
// Monitor buffer pool usage
// JMX: kafka.producer:type=producer-metrics,client-id=*,name=buffer-available-bytesAcknowledgment Strategies Deep Dive
ACK Levels and Durability Guarantees
Understanding acknowledgment strategies is crucial for balancing performance with data reliability:
PRODUCER ──────────────────▶ BROKER "send and forget" Characteristics: ├── Highest throughput (no waiting) ├── Lowest latency (~0.1ms) ├── No durability guarantee ├── Message loss on network failures └── Use case: Metrics, non-critical logs
┌──────────┐ ┌──────────────┐ ┌────────────┐ │ PRODUCER │─────────────▶│ LEADER BROKER│◀─────────────│ FOLLOWER 1 │ └──────────┘ "wait for └──────┬───────┘ async fetch └────────────┘ leader" │ └─────────────────────▶ FOLLOWER 2 Timeline: 1. Producer sends message 2. Leader writes to local log 3. Leader sends ACK to producer ← ACK HERE 4. Followers fetch asynchronously Risk: Data loss if leader fails before replication
┌──────────┐ ┌──────────────┐ ┌────────────────┐ │ PRODUCER │─────────────▶│ LEADER BROKER│◀─────────────│ FOLLOWER 1 ISR │ └──────────┘ "wait for └──────┬───────┘ sync write └────────────────┘ all ISR" │ └─────────────────────▶ FOLLOWER 2 (ISR) Timeline: 1. Producer sends message 2. Leader writes to local log 3. Leader waits for ISR followers to replicate 4. All ISR members confirm write 5. Leader sends ACK to producer ← ACK HERE Guarantee: Durable as long as one ISR member survives
Production ACK Configuration Patterns
High Durability (Financial Systems):
Properties financialProps = new Properties();
financialProps.put(ProducerConfig.ACKS_CONFIG, "all");
financialProps.put(ProducerConfig.RETRIES_CONFIG, Integer.MAX_VALUE);
financialProps.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);
// Broker-level protection
// min.insync.replicas=2 (at least 2 replicas must acknowledge)Balanced Performance (Most Applications):
Properties balancedProps = new Properties();
balancedProps.put(ProducerConfig.ACKS_CONFIG, "1");
balancedProps.put(ProducerConfig.RETRIES_CONFIG, 3);
balancedProps.put(ProducerConfig.REQUEST_TIMEOUT_MS_CONFIG, 30000);High Throughput (Metrics/Logs):
Properties throughputProps = new Properties();
throughputProps.put(ProducerConfig.ACKS_CONFIG, "0");
throughputProps.put(ProducerConfig.LINGER_MS_CONFIG, 100);
throughputProps.put(ProducerConfig.BATCH_SIZE_CONFIG, 131072); // 128KBFailure Scenarios and Impact Analysis
Scenario: Network split between leader and one ISR follower Before Split: ISR = [Broker-1, Broker-2, Broker-3] After Split: ISR = [Broker-1, Broker-2] (Broker-3 removed) Producer Impact: ├── Continues with reduced ISR ├── Latency may increase slightly ├── Still maintains durability guarantee └── Automatic recovery when partition heals
Leader Failure Analysis:
// Configuration for leader failure resilience
props.put(ProducerConfig.RETRIES_CONFIG, Integer.MAX_VALUE);
props.put(ProducerConfig.RETRY_BACKOFF_MS_CONFIG, 100);
props.put(ProducerConfig.DELIVERY_TIMEOUT_MS_CONFIG, 300000); // 5 minutes total
// Leadership change handling:
// 1. In-flight requests fail with NOT_LEADER_FOR_PARTITION
// 2. Producer refreshes metadata
// 3. Discovers new leader
// 4. Retries failed requests automaticallyBatching and Performance Optimization
Batching Mechanics and Timeline
Kafka’s batching system is the key to achieving high throughput:
T=0ms: [Message A] ──┐ T=5ms: [Message B] ──┼─── Batch Building T=8ms: [Message C] ──┤ T=12ms: [Message D] ──┘ T=20ms: BATCH SENT ──────────▶ BROKER │ └─ Triggered by linger.ms timeout Alternative Triggers: ├── batch.size reached (32KB default) ├── linger.ms timeout (0ms default) ├── Buffer memory pressure └── Explicit flush() call
Advanced Batching Configuration
Throughput-Optimized Configuration:
Properties throughputConfig = new Properties();
// Batching settings
throughputConfig.put(ProducerConfig.BATCH_SIZE_CONFIG, 131072); // 128KB
throughputConfig.put(ProducerConfig.LINGER_MS_CONFIG, 50); // 50ms wait
throughputConfig.put(ProducerConfig.BUFFER_MEMORY_CONFIG, 268435456); // 256MB
// Network optimization
throughputConfig.put(ProducerConfig.MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION, 5);
throughputConfig.put(ProducerConfig.COMPRESSION_TYPE_CONFIG, "lz4");
// Result: ~10x throughput improvement over default settings// Compression impact analysis // Data: JSON messages, 1KB average size compressionType="none": Bandwidth: 100MB/s, CPU: Low compressionType="gzip": Bandwidth: 25MB/s, CPU: High, Ratio: 4:1 compressionType="snappy": Bandwidth: 40MB/s, CPU: Medium, Ratio: 2.5:1 compressionType="lz4": Bandwidth: 50MB/s, CPU: Low, Ratio: 2:1 // Recommendation: lz4 for best balance
Performance Tuning Methodology
Step 1: Baseline Measurement
// Performance measurement code
public class ProducerBenchmark {
private long messages = 0;
private long bytes = 0;
private long startTime = System.currentTimeMillis();
private Callback measurementCallback = (metadata, exception) -> {
if (exception == null) {
messages++;
bytes += recordSize;
if (messages % 10000 == 0) {
long elapsed = System.currentTimeMillis() - startTime;
double throughputMsgs = (messages * 1000.0) / elapsed;
double throughputMB = (bytes * 1000.0) / (elapsed * 1024 * 1024);
System.out.printf("Messages/sec: %.2f, MB/sec: %.2f%n",
throughputMsgs, throughputMB);
}
}
};
}Step 2: Systematic Optimization
// Optimization progression
public class OptimizationSteps {
// Step 1: Increase batch size
void optimizeBatching() {
// Start: 16KB → Test: 32KB, 64KB, 128KB
// Monitor: Memory usage, latency impact
}
// Step 2: Tune linger time
void optimizeLinger() {
// Start: 0ms → Test: 10ms, 25ms, 50ms, 100ms
// Balance: Throughput vs latency SLA
}
// Step 3: Optimize compression
void optimizeCompression() {
// Test: lz4, snappy, gzip
// Monitor: CPU usage, network bandwidth
}
// Step 4: Network tuning
void optimizeNetwork() {
// socket.send.buffer.bytes
// max.in.flight.requests.per.connection
}
}Production Monitoring Integration:
// JMX metrics to monitor
public class ProducerMetrics {
private final MBeanServer server = ManagementFactory.getPlatformMBeanServer();
public void logPerformanceMetrics() {
// Throughput metrics
double recordSendRate = getMetricValue(
"kafka.producer:type=producer-metrics,client-id=*,name=record-send-rate");
double byteRate = getMetricValue(
"kafka.producer:type=producer-metrics,client-id=*,name=byte-rate");
// Latency metrics
double avgLatency = getMetricValue(
"kafka.producer:type=producer-metrics,client-id=*,name=record-send-total");
// Batch metrics
double batchSizeAvg = getMetricValue(
"kafka.producer:type=producer-metrics,client-id=*,name=batch-size-avg");
double recordsPerBatch = getMetricValue(
"kafka.producer:type=producer-metrics,client-id=*,name=records-per-request-avg");
System.out.printf("Throughput: %.2f records/sec, %.2f MB/sec%n",
recordSendRate, byteRate / (1024 * 1024));
System.out.printf("Batching: %.2f KB avg, %.2f records/batch%n",
batchSizeAvg / 1024, recordsPerBatch);
}
}Retry Mechanisms and Error Handling
Error Classification and Handling Strategy
Kafka producers deal with two main categories of errors:
Retriable Errors:
// Network and coordination errors
TimeoutException.class // Request timeout
NotLeaderForPartitionException.class // Leadership change
NetworkException.class // Connection issues
UnknownTopicOrPartitionException.class // Metadata stale
// Handling: Automatic retry with backoff
props.put(ProducerConfig.RETRIES_CONFIG, Integer.MAX_VALUE);
props.put(ProducerConfig.RETRY_BACKOFF_MS_CONFIG, 100);Non-Retriable Errors:
// Client and data errors
SerializationException.class // Bad data format
RecordTooLargeException.class // Message size exceeded
InvalidRequiredAcksException.class // Invalid acks value
// Handling: Immediate failure, no retry
// Application must handle these errors explicitlyAdvanced Retry Configuration
Production Retry Strategy:
Properties retryConfig = new Properties();
// Retry settings
retryConfig.put(ProducerConfig.RETRIES_CONFIG, Integer.MAX_VALUE);
retryConfig.put(ProducerConfig.RETRY_BACKOFF_MS_CONFIG, 100);
retryConfig.put(ProducerConfig.DELIVERY_TIMEOUT_MS_CONFIG, 300000); // 5 minutes
// Timeout hierarchy
retryConfig.put(ProducerConfig.REQUEST_TIMEOUT_MS_CONFIG, 30000); // Per request: 30s
retryConfig.put(ProducerConfig.MAX_BLOCK_MS_CONFIG, 60000); // Metadata fetch: 60s
// Retry behavior: exponential backoff with jitter
// Attempt 1: 100ms
// Attempt 2: 200ms + jitter
// Attempt 3: 400ms + jitter
// ... continues until delivery.timeout.msCircuit Breaker Implementation
public class ProducerCircuitBreaker {
private final AtomicInteger failures = new AtomicInteger(0);
private final AtomicLong lastFailureTime = new AtomicLong(0);
private final int failureThreshold;
private final long recoveryTimeoutMs;
private volatile CircuitState state = CircuitState.CLOSED;
public enum CircuitState { CLOSED, OPEN, HALF_OPEN }
public CompletableFuture<RecordMetadata> send(ProducerRecord<String, String> record) {
if (state == CircuitState.OPEN) {
if (System.currentTimeMillis() - lastFailureTime.get() > recoveryTimeoutMs) {
state = CircuitState.HALF_OPEN;
} else {
return CompletableFuture.failedFuture(
new RuntimeException("Circuit breaker OPEN"));
}
}
CompletableFuture<RecordMetadata> future = new CompletableFuture<>();
producer.send(record, (metadata, exception) -> {
if (exception == null) {
onSuccess();
future.complete(metadata);
} else {
onFailure(exception);
future.completeExceptionally(exception);
}
});
return future;
}
private void onSuccess() {
failures.set(0);
state = CircuitState.CLOSED;
}
private void onFailure(Exception exception) {
int currentFailures = failures.incrementAndGet();
lastFailureTime.set(System.currentTimeMillis());
if (currentFailures >= failureThreshold) {
state = CircuitState.OPEN;
}
}
}Dead Letter Queue Pattern
public class DeadLetterProducer {
private final KafkaProducer<String, String> mainProducer;
private final KafkaProducer<String, String> dlqProducer;
private final String dlqTopic;
public void sendWithDLQ(ProducerRecord<String, String> record) {
mainProducer.send(record, (metadata, exception) -> {
if (exception != null) {
handleFailure(record, exception);
}
});
}
private void handleFailure(ProducerRecord<String, String> originalRecord,
Exception exception) {
// Add failure metadata to headers
Headers dlqHeaders = originalRecord.headers();
dlqHeaders.add("original.topic", originalRecord.topic().getBytes());
dlqHeaders.add("failure.timestamp",
String.valueOf(System.currentTimeMillis()).getBytes());
dlqHeaders.add("failure.reason", exception.getMessage().getBytes());
dlqHeaders.add("failure.class", exception.getClass().getName().getBytes());
// Send to dead letter queue
ProducerRecord<String, String> dlqRecord = new ProducerRecord<>(
dlqTopic,
originalRecord.key(),
originalRecord.value(),
dlqHeaders
);
dlqProducer.send(dlqRecord, (dlqMetadata, dlqException) -> {
if (dlqException != null) {
// Log critical error - both main and DLQ failed
logger.error("Failed to send to DLQ: {}", dlqException.getMessage());
}
});
}
}Idempotency and Deduplication
Idempotent Producer Mechanics
Kafka’s idempotent producer eliminates duplicate messages through sequence numbering:
Producer Broker │ │ │ ─── Message (seq=0) ───────────────────▶ │ ─── Store seq=0 ─── │ ◀─── ACK (seq=0) ─────────────────────── │ │ │ │ ─── Message (seq=1) ───────────────────▶ │ ─── Store seq=1 ─── │ [Network failure] │ │ ─── Message (seq=1) [retry] ───────────▶ │ ─── Duplicate, ignore ─── │ ◀─── ACK (seq=1) ─────────────────────── │ Key Components: ├── Producer ID (PID): Unique identifier per producer ├── Sequence Number: Per partition sequence counter ├── Epoch: Prevents zombie producers └── Broker-side deduplication: Based on PID + sequence
Configuration and Implementation
Enable Idempotency:
Properties idempotentConfig = new Properties();
// Enable idempotency (automatically sets other required configs)
idempotentConfig.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);
// Automatically configured (cannot be overridden):
// acks = "all"
// retries = Integer.MAX_VALUE
// max.in.flight.requests.per.connection = 5Sequence Number Management:
// Internal producer state (not exposed in API)
class ProducerStateManager {
private final ConcurrentHashMap<TopicPartition, Integer> sequenceNumbers;
private final long producerId;
private final short epoch;
// Sequence numbers are per partition and start at 0
// Broker tracks expected sequence per (PID, TopicPartition)
int nextSequence(TopicPartition tp) {
return sequenceNumbers.compute(tp, (k, v) -> v == null ? 0 : v + 1);
}
}Transactional Producers
Exactly-Once Semantics:
public class TransactionalProducerExample {
private final KafkaProducer<String, String> producer;
public TransactionalProducerExample() {
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "my-transaction-id");
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);
producer = new KafkaProducer<>(props);
producer.initTransactions();
}
public void sendTransactionally(List<ProducerRecord<String, String>> records) {
producer.beginTransaction();
try {
// Send all records in transaction
for (ProducerRecord<String, String> record : records) {
producer.send(record);
}
// Commit transaction (all-or-nothing)
producer.commitTransaction();
} catch (Exception e) {
// Abort transaction on any failure
producer.abortTransaction();
throw e;
}
}
}Producer Transaction Coordinator Partition Leader │ │ │ │ ── InitTransactions ───▶ │ │ │ ◀── TxnId + Epoch ────── │ │ │ │ │ │ ── BeginTransaction ───▶ │ │ │ │ │ │ ── Send Records ─────────────────────────────────────▶ │ │ │ ◀── Register Partition ──── │ │ │ │ │ ── CommitTransaction ──▶ │ │ │ │ ── WriteTxnMarkers ───────▶ │ │ │ ◀── Marker ACK ──────────── │ │ ◀── Transaction Done ─── │ │
Production Idempotency Patterns
Database + Kafka Exactly-Once:
public class ExactlyOnceProcessor {
private final KafkaProducer<String, String> producer;
private final DataSource dataSource;
@Transactional
public void processMessage(ConsumerRecord<String, String> record) {
// Extract idempotency key from message
String idempotencyKey = record.headers().lastHeader("idempotency-key")
.value().toString();
// Check if already processed (database)
if (isAlreadyProcessed(idempotencyKey)) {
return; // Skip duplicate processing
}
// Process business logic
BusinessEvent event = processBusinessLogic(record.value());
// Start Kafka transaction
producer.beginTransaction();
try {
// Store processing result in database
storeResult(idempotencyKey, event);
// Send result to Kafka
ProducerRecord<String, String> outputRecord =
new ProducerRecord<>("output-topic", event.toJson());
producer.send(outputRecord);
// Commit both database and Kafka transaction
producer.commitTransaction();
} catch (Exception e) {
producer.abortTransaction();
throw e;
}
}
}Serialization and Compression
Serialization Performance Analysis
// Performance comparison (1M messages, 1KB each) StringSerializer: ├── Throughput: 150k msgs/sec ├── CPU Usage: Low └── Memory: Minimal ByteArraySerializer: ├── Throughput: 200k msgs/sec ├── CPU Usage: Minimal └── Memory: Direct byte handling JSONSerializer (custom): ├── Throughput: 80k msgs/sec ├── CPU Usage: High (parsing) └── Memory: Object creation overhead AvroSerializer: ├── Throughput: 120k msgs/sec ├── CPU Usage: Medium ├── Memory: Schema caching └── Benefits: Schema evolution, compact binary
Custom Serializer Implementation
public class OptimizedJsonSerializer implements Serializer<BusinessEvent> {
private final ObjectMapper objectMapper;
private final ByteArrayOutputStream buffer = new ByteArrayOutputStream();
public OptimizedJsonSerializer() {
this.objectMapper = new ObjectMapper()
.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
}
@Override
public byte[] serialize(String topic, BusinessEvent data) {
if (data == null) {
return null;
}
try {
// Reuse buffer to avoid allocations
buffer.reset();
objectMapper.writeValue(buffer, data);
return buffer.toByteArray();
} catch (Exception e) {
throw new SerializationException("Error serializing JSON", e);
}
}
}Compression Strategy Selection
public class CompressionBenchmark {
// Test data: JSON messages, mixed sizes
void benchmarkCompression() {
// LZ4: Fast compression/decompression
testCompression("lz4",
compressionRatio: 2.1,
compressionSpeed: 300_MB_per_sec,
decompressionSpeed: 800_MB_per_sec,
cpuUsage: "Low");
// Snappy: Balanced performance
testCompression("snappy",
compressionRatio: 2.3,
compressionSpeed: 250_MB_per_sec,
decompressionSpeed: 500_MB_per_sec,
cpuUsage: "Medium");
// GZIP: Best compression ratio
testCompression("gzip",
compressionRatio: 3.2,
compressionSpeed: 50_MB_per_sec,
decompressionSpeed: 300_MB_per_sec,
cpuUsage: "High");
}
}
// Production recommendation matrix:
//
// High Throughput Systems: Use LZ4
// Network-Limited Systems: Use GZIP
// Balanced Systems: Use Snappy
// CPU-Limited Systems: Use noneMonitoring and Observability
Essential Producer Metrics
JMX Metrics Collection:
public class ProducerMonitoring {
private final MBeanServer mBeanServer;
public ProducerHealthMetrics getHealthMetrics() {
return ProducerHealthMetrics.builder()
.recordSendRate(getMetric("record-send-rate"))
.byteRate(getMetric("byte-rate"))
.recordErrorRate(getMetric("record-error-rate"))
.recordRetryRate(getMetric("record-retry-rate"))
.batchSizeAvg(getMetric("batch-size-avg"))
.recordsPerRequestAvg(getMetric("records-per-request-avg"))
.requestLatencyAvg(getMetric("request-latency-avg"))
.bufferAvailableBytes(getMetric("buffer-available-bytes"))
.bufferTotalBytes(getMetric("buffer-total-bytes"))
.build();
}
private double getMetric(String metricName) {
try {
ObjectName objectName = new ObjectName(
"kafka.producer:type=producer-metrics,client-id=*,name=" + metricName);
return (Double) mBeanServer.getAttribute(objectName, "Value");
} catch (Exception e) {
return 0.0;
}
}
}Production Alerting Thresholds
Producer Error Rate: threshold: > 1% window: 5 minutes description: "High producer error rate indicates broker issues" Buffer Memory Exhaustion: threshold: buffer-available-bytes < 10MB window: 2 minutes description: "Producer buffer full, may block application threads" Request Timeout Rate: threshold: > 0.1% window: 5 minutes description: "High timeout rate indicates network or broker issues"
Low Throughput: threshold: record-send-rate < expected_baseline * 0.7 window: 10 minutes description: "Producer throughput below baseline" High Latency: threshold: request-latency-avg > 100ms window: 5 minutes description: "Producer requests taking longer than expected" Poor Batching Efficiency: threshold: records-per-request-avg < 10 window: 15 minutes description: "Poor batching may indicate configuration issues"
Troubleshooting Playbook
Performance Degradation Investigation:
public class ProducerDiagnostics {
public void diagnoseLowThroughput() {
// Step 1: Check batching efficiency
double recordsPerBatch = getMetric("records-per-request-avg");
if (recordsPerBatch < 10) {
System.out.println("Poor batching detected. Check:");
System.out.println("- linger.ms setting (increase for better batching)");
System.out.println("- batch.size setting (may be too small)");
System.out.println("- Traffic pattern (low message rate?)");
}
// Step 2: Check memory pressure
double bufferAvailable = getMetric("buffer-available-bytes");
double bufferTotal = getMetric("buffer-total-bytes");
double memoryUtilization = (bufferTotal - bufferAvailable) / bufferTotal;
if (memoryUtilization > 0.8) {
System.out.println("High memory pressure detected. Check:");
System.out.println("- buffer.memory setting (increase if needed)");
System.out.println("- Consumer lag (causing producer blocking?)");
System.out.println("- Network issues (preventing batch sends?)");
}
// Step 3: Check error rates
double errorRate = getMetric("record-error-rate");
if (errorRate > 0.01) { // 1%
System.out.println("High error rate detected. Check:");
System.out.println("- Broker health and connectivity");
System.out.println("- Authentication/authorization issues");
System.out.println("- Message size limits");
}
}
}Network Issues Diagnosis:
public void diagnoseNetworkIssues() {
double requestLatency = getMetric("request-latency-avg");
double timeoutRate = getMetric("request-timeout-rate");
if (requestLatency > 50 && timeoutRate > 0.001) {
System.out.println("Network issues detected:");
System.out.println("1. Check broker connectivity: telnet broker-host 9092");
System.out.println("2. Check DNS resolution time");
System.out.println("3. Monitor broker-side metrics");
System.out.println("4. Consider increasing request.timeout.ms");
System.out.println("5. Check for packet loss or high RTT");
}
}Production Integration Summary
This deep dive into Kafka producer mechanics provides the technical foundation needed for implementing high-performance, reliable data ingestion systems. Key takeaways for production systems:
Performance Optimization:
- Implement systematic batching with appropriate
linger.msandbatch.size - Use compression (
lz4recommended) for network efficiency - Monitor and tune memory allocation for optimal throughput
Reliability Patterns:
- Choose appropriate
ackslevel based on durability requirements - Implement comprehensive retry strategies with circuit breakers
- Use idempotent producers for exactly-once semantics when needed
Operational Excellence:
- Establish comprehensive monitoring with proper alerting thresholds
- Implement structured troubleshooting procedures
- Plan for failure scenarios with dead letter queues and error handling
See Also: Consumer Groups & Rebalancing, Transactions & Exactly-Once