<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kafka on Chen Kai Blog</title><link>https://www.chenk.top/en/tags/kafka/</link><description>Recent content in Kafka on Chen Kai Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 19 Jul 2025 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/en/tags/kafka/index.xml" rel="self" type="application/rss+xml"/><item><title>System Design (5): Message Queues and Event-Driven Architecture</title><link>https://www.chenk.top/en/system-design/05-message-queues/</link><pubDate>Sat, 19 Jul 2025 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/system-design/05-message-queues/</guid><description>&lt;p>In 2011, LinkedIn&amp;rsquo;s engineering team was struggling with a problem that many growing companies face. Their monolithic application had become a web of tightly-coupled services, each making synchronous calls to half a dozen others. When any single service went down, cascading failures rippled through the entire system. Deploying a change to one service required coordinating with every team whose service it called.&lt;/p>
&lt;p>Their solution was Apache Kafka — a distributed event log that decoupled producers from consumers. Instead of Service A calling Service B directly, Service A writes an event to Kafka, and Service B reads it when it is ready. If Service B is down, the events wait. If Service B is slow, it processes at its own pace. The producer does not need to know or care about the consumer.&lt;/p></description></item></channel></rss>