Why Retention policies (time-based, size-based) in Kafka? - Purpose & Use Cases

The Big Idea

What if your system could clean itself automatically, saving you hours of headache?

The Scenario

Imagine you run a busy message system where data piles up every second. Without any rules, your storage fills up fast, and old messages clog the system.

The Problem

Manually deleting old messages or limiting storage is slow and risky. You might delete important data by mistake or run out of space unexpectedly, causing system crashes.

The Solution

Retention policies automatically remove old or excess data based on time or size limits. This keeps your system clean and reliable without constant manual work.

Before vs After

✗ Before

while (storageFull()) { deleteOldMessages(); }

✓ After

setRetentionPolicy(time='7d', size='10GB')

What It Enables

It lets your system manage data smartly, freeing you to focus on building features instead of cleaning up storage.

Real Life Example

A chat app keeps messages only for 30 days or until 5GB of data, so users get fresh chats and the server never runs out of space.

Key Takeaways

Manual cleanup is slow and error-prone.

Retention policies automate data removal by time or size.

This keeps systems efficient and reliable without extra effort.

Practice

1. What does the retention.ms setting control in Kafka?

easy

A. The maximum size of a Kafka topic

B. How long Kafka keeps data before deleting it

C. The number of partitions in a topic

D. The replication factor of a topic

Solution

1. Step 1: Understand retention.ms meaning

   retention.ms sets the time duration Kafka retains data before deletion.

2. Step 2: Compare with other options

   Other options relate to size, partitions, or replication, not time retention.

3. Final Answer:

   How long Kafka keeps data before deleting it -> Option B

4. Quick Check:

   retention.ms = time-based retention [OK]

Hint: Remember ms means milliseconds, so it's about time [OK]

Common Mistakes:

• Confusing retention.ms with retention.bytes
• Thinking it controls topic size
• Mixing it with partition count

2. Which of the following is the correct way to set a size-based retention policy in Kafka's topic configuration?

easy

A. "retention.bytes" = 1073741824

B. "retention.time" = 604800000

C. "retention.size" = 1073741824

D. "retention.ms" = 1073741824

Solution

1. Step 1: Identify correct property for size-based retention

   The correct property is retention.bytes for size limits.

2. Step 2: Check option values and names

   "retention.bytes" = 1073741824 uses retention.bytes with a size value (1GB). Others use wrong keys or time-based keys.

3. Final Answer:

   "retention.bytes" = 1073741824 -> Option A

4. Quick Check:

   Size retention uses retention.bytes [OK]

Hint: Size retention uses bytes, so look for retention.bytes [OK]

Common Mistakes:

• Using retention.time instead of retention.ms
• Using retention.size which is invalid
• Confusing retention.ms with size setting

3. Given a Kafka topic with retention.ms=60000 and retention.bytes=1048576, what happens when the topic data reaches 2MB before 60 seconds pass?

medium

A. Kafka waits until 60 seconds pass before deleting any data

B. Kafka deletes data only if both time and size limits are reached

C. Kafka deletes old data immediately because size limit is reached

D. Kafka ignores retention settings and keeps all data

Solution

1. Step 1: Understand retention.ms and retention.bytes interaction

   Kafka deletes data when either time or size limit is reached, whichever comes first.

2. Step 2: Analyze given values

   Size limit is 1MB, data reached 2MB before 60 seconds, so size limit triggers deletion immediately.

3. Final Answer:

   Kafka deletes old data immediately because size limit is reached -> Option C

4. Quick Check:

   Retention triggers on earliest limit reached [OK]

Hint: Retention deletes when time OR size limit is reached [OK]

Common Mistakes:

• Thinking both limits must be reached to delete
• Assuming time limit always overrides size
• Ignoring size limit when time not reached

4. You set retention.ms to a negative value in Kafka topic config. What is the likely outcome?

medium

A. Kafka treats it as infinite retention (never deletes data)

B. Kafka throws a configuration error and refuses to start

C. Kafka deletes data immediately after creation

D. Kafka uses default retention time instead

Solution

1. Step 1: Check Kafka behavior for negative retention.ms

   Kafka interprets negative retention.ms as infinite retention, meaning no data deletion.

2. Step 2: Confirm other options

   Kafka does not throw error or delete immediately; it does not revert to default automatically.

3. Final Answer:

   Kafka treats it as infinite retention (never deletes data) -> Option A

4. Quick Check:

   Negative retention.ms means infinite retention [OK]

Hint: Negative retention.ms disables deletion, keeps data forever [OK]

Common Mistakes:

• Expecting an error on negative value
• Assuming immediate deletion
• Thinking default value applies automatically

5. You want to configure a Kafka topic to keep data for 2 hours or up to 500MB, whichever limit is reached first. Which configuration is correct?

hard

A. "retention.ms"=7200000 only, size limit is not needed

B. "retention.ms"=7200000 and "retention.bytes"=5000000000

C. "retention.ms"=120 and "retention.bytes"=524288000

D. "retention.ms"=7200000 and "retention.bytes"=524288000

Solution

1. Step 1: Convert 2 hours to milliseconds

   2 hours = 2 * 60 * 60 * 1000 = 7,200,000 ms.

2. Step 2: Convert 500MB to bytes

   500MB = 500 * 1024 * 1024 = 524,288,000 bytes.

3. Step 3: Match values to options

   "retention.ms"=7200000 and "retention.bytes"=524288000 matches both correct values; others have wrong size or time values.

4. Final Answer:

   "retention.ms"=7200000 and "retention.bytes"=524288000 -> Option D

5. Quick Check:

   2 hours = 7200000 ms, 500MB = 524288000 bytes [OK]

Hint: Convert hours to ms and MB to bytes carefully [OK]

Common Mistakes:

• Using seconds instead of milliseconds for retention.ms
• Confusing MB with bytes without conversion
• Setting only one limit when both are needed