Lesson 04: The Firehose

Stream Processing

If you are processing 1 million events per second (e.g., website clickstreams, IoT telemetry), a traditional Message Queue will quickly buckle. You need a Distributed Event Streaming Platform like Apache Kafka.

Kafka is fundamentally different from a Message Queue. It does not delete messages after they are read. It treats a Topic as a persistent, distributed, append-only log on disk.

Partitions and Consumer Groups

To scale, Kafka splits a single Topic into multiple Partitions. Each partition lives on a different physical server. Instead of having a single application instance try to read 1M events/sec, you spin up a Consumer Group of multiple servers.

Kafka automatically assigns specific Partitions to specific Consumers. This allows you to process the firehose in parallel.

Kafka Partition Rebalancing

Click "Add Consumer" to scale out your application. Notice how Kafka automatically reassigns the partitions to keep the workload balanced across all active nodes.

Topic: clickstreams
Consumer Group
1 Node processing 4 Partitions. High CPU load!

The End of the Track

Congratulations. You've made it through the Distributed Systems track. You've explored Consensus algorithms, Hash rings, Sagas, and Event Sourcing.

Building distributed systems is hard. The network is unreliable, latency is unpredictable, and clocks are not synchronized. But by applying these architectural patterns, you can build systems that scale to millions of users and survive massive infrastructure failures.

Check yourself

1. How does Kafka scale out the processing of a massive firehose of events?

Partitions are the unit of concurrency in Kafka. If you have 10 partitions, you can have up to 10 consumer nodes processing data in parallel.