Replication & Fault Tolerance

Use MirrorMaker 2 to replicate between regional clusters, choosing active-passive for simple safe disaster recovery or active-active for low local latency at the cost of conflict handling and offset translation.

Frequent leader movement means repeated NOT_LEADER_FOR_PARTITION errors, metadata refreshes, retries, lag bumps, coordination load, and shrinking ISR -- stabilize by fixing the root cause, avoiding needless elections, and monitoring leader count per broker.

The controller is the one elected broker that manages broker membership and partition leadership; on a leader's failure it elects a new leader from the ISR, which already holds all committed data, so the partition stays available with no acknowledged data lost.

Compatibility modes let producers and consumers upgrade independently, and a new field is only safe to add if it has a default so old data remains readable.

JsonDeserializer with trusted packages safely turns JSON bytes into your type, and you pause or resume a live listener through the endpoint registry when a downstream like the database is down.

Wrap the deserializer so a bad payload becomes a handled error, and let DefaultErrorHandler retry with backoff, classify the exception, and route exhausted records to a dead letter topic.

The producer throws RecordTooLargeException above one megabyte, and you fix it by raising the limits at every layer, compressing, or sending a claim-check reference instead of the blob.

Fault tolerance is surviving failures without loss, and Kafka gets it from replication, ISR-based leader election, and acks=all with min.insync.replicas.

min.insync.replicas sets the minimum replicas that must persist a record for an acks=all write to succeed, so together they guarantee durability by refusing writes that cannot be safely replicated.

Kafka's default message cap is about one megabyte enforced at broker, producer, and consumer, so to send bigger you must raise message.max.bytes, max.request.size, and the consumer fetch size together, or send a reference instead.

The replication factor is how many copies of each partition Kafka keeps across brokers, and it controls how many failures the topic can survive.

The leader serves all reads and writes, followers copy it, and the ISR is the caught-up replicas eligible to take over.

With `min.insync.replicas=1`, `acks=all` degrades to acknowledged by the leader alone whenever followers are out of sync, so a single broker failure can lose an already-acknowledged write -- set `min.insync.replicas=2` for real durability.