/var/kafka/data/payments.processed-0/
  00000000000000000000.log      ← segment 0: offsets 0–999,999
  00000000000000000000.index    ← sparse offset index (offset → file byte position)
  00000000000000000000.timeindex← sparse timestamp index
  00000000000001000000.log      ← segment 1: offsets 1,000,000–1,999,999
  00000000000001000000.index
  leader-epoch-checkpoint       ← monotonic counter incremented on leader change

// ❌ No key — round-robin distribution, no ordering guarantee
await producer.send({
  topic: 'payments.processed',
  messages: [{ value: JSON.stringify({ paymentId: 'P1', status: 'completed' }) }]
})

// ✅ Key = partition determinism + ordering within a payment's lifecycle
await producer.send({
  topic: 'payments.processed',
  messages: [{
    key:   'payment:P1',   // hash(key) % numPartitions = same partition every time
    value: JSON.stringify({ paymentId: 'P1', status: 'completed' }),
  }]
})
// payment:P1 always lands on partition 3
// payment:P2 always lands on partition 1
// All events for P1 arrive at consumer in the order they were written

// ❌ acks=0 — fire and forget. No durability. Use only for metrics you can afford to lose.
const producer = kafka.producer({ acks: 0 })

// ❌ acks=1 (default) — leader writes to local disk, acks immediately.
// Risk: leader crashes before follower fetches → message lost permanently.
const producer = kafka.producer({ acks: 1 })

// ✅ acks=all (-1) — leader waits for ALL in-sync replicas to write before acking.
// Combined with min.insync.replicas=2: tolerates one broker failure with zero data loss.
const producer = kafka.producer({ acks: -1 })

// ✅ Cooperative rebalancing — only affected partitions are revoked
const consumer = kafka.consumer({
  groupId: 'payments-service',
  partitionAssigners: [PartitionAssigners.roundRobin],
  // kafkajs uses CooperativeStickyAssignor when available in broker
  rebalanceTimeout: 60000,
})

consumer.on(consumer.events.REBALANCING, async () => {
  // With cooperative protocol: only revoked partitions pause
  // Unaffected partitions continue processing during rebalance
  metrics.increment('consumer.rebalance')
})

# KRaft cluster: controller nodes are separate from broker nodes (production)
# Controller quorum (odd number for Raft): 3 or 5 nodes
# Broker nodes: any number

# Check KRaft mode
kafka-metadata-quorum.sh --bootstrap-controller localhost:9093 describe --status
# Output: LeaderId, LeaderEpoch, HighWatermark, MaxFollowerLag

// ✅ Compacted topic: Kafka retains only the latest value per key
// Config: cleanup.policy=compact (instead of delete)

// These three publishes for the same user ID:
await producer.send({ topic: 'user-profiles', messages: [
  { key: 'user:42', value: JSON.stringify({ name: 'Alice', plan: 'free' }) },
  { key: 'user:42', value: JSON.stringify({ name: 'Alice', plan: 'pro' }) },   // plan upgrade
  { key: 'user:42', value: JSON.stringify({ name: 'Alice', plan: 'pro', mfa: true }) }, // MFA added
]})

// After compaction: only the third record for user:42 is retained
// New consumers starting from offset=0 still see the full current state of every key
// Tombstone (null value): deletes the key from the compacted log entirely
await producer.send({ topic: 'user-profiles', messages: [
  { key: 'user:42', value: null }  // tombstone — user deleted
]})