LinkedIn ב-2011 עמד בפני בעיה: כל פעם שuser עושה action - חיבור חדש, like, view - עשרות שירותים שונים צריכים לדעת על זה. ה-notification service, ה-analytics service, ה-recommendation engine, ה-email service. בארכיטקטורה synchronous, user action מחכה שכל 10 השירותים יסיימו לפני שמקבל response. אם שירות אחד נופל - כל ה-flow נתקע. LinkedIn פיתח Kafka כדי לפתור את זה.
Message Queue הוא תשתית שמאפשרת לservices לתקשר asynchronously - Producer שולח message לqueue, Consumer קורא ומעבד בזמן שנוח לו. Producer לא יודע ולא צריך לדעת מי ה-Consumer, מתי הוא יעבד, ואפילו אם הוא קיים ברגע השליחה.
LinkedIn ב-2024 מריצה Kafka עם יותר מ-7 טריליון messages ביום. Uber משתמשת בKafka לכל ride event, location update, ו-surge pricing calculation - מיליארדי events ביום. Airbnb, Twitter, Netflix, Spotify, Goldman Sachs - כולם מריצים Kafka בproduction. זה לא tool נישה - זה infrastructure שנמצא בלב של כל מערכת distributed בscale.
Jay Kreps, אחד מממציאי Kafka בLinkedIn, תיאר את ה-insight הבסיסי של Kafka בסדרת blog posts שכדאי לקרוא: הוא הבין שmessage queues קיימות חושבות על עצמן כtransient buffers - message נכנס, נקרא, נמחק. אבל מה אם הqueue תחשוב על עצמה כlog? כindex immutable של events? אז פתאום אפשר לreplay events, לקרוא מoffset ישן, לbuild views שונות על אותה data. זה מה שהוביל ל-Kafka's design - לא עוד transient buffer, אלא "distributed log" שמייצג truth של מה קרה. כל consumer שמגיע אחרי יכול לקרוא את כל ה-history. זה revolutionary בהשוואה ל-RabbitMQ ו-ActiveMQ שלפניו.