Czym jest Apache Kafka i do czego służy?

Kafka pojawia się w ogłoszeniach o pracy dla backendowców, w opisach architektury i na rozmowach rekrutacyjnych, choć wiele osób uczących się programowania nie spotkało jej jeszcze w żadnym projekcie. Ten artykuł wyjaśnia, czym jest Apache Kafka, jak działają jej podstawowe pojęcia (topic, partycja, offset, grupa konsumentów), czym różni się od kolejek takich jak RabbitMQ i czy trzeba ją znać na początku kariery. Zaznaczam od razu: nie uruchomiłem do tego artykułu brokera Kafki, więc opisy opieram na oficjalnej dokumentacji, a w kodzie sprawdziłem tylko to, co dało się sprawdzić bez brokera. Zaznaczam to przy każdym przykładzie.

Czym jest Apache Kafka?

Według oficjalnej dokumentacji Kafka to rozproszony system złożony z serwerów i klientów, służący do przetwarzania strumieni zdarzeń (event streaming). Dokumentacja porównuje strumieniowanie zdarzeń do układu nerwowego człowieka: informacje o tym, co się dzieje w firmie, płyną w czasie rzeczywistym tam, gdzie są potrzebne. Kafka daje trzy możliwości:

1. Publikowanie i subskrybowanie strumieni zdarzeń (zapis i odczyt).
2. Trwałe przechowywanie zdarzeń, „tak długo, jak chcesz”.
3. Przetwarzanie zdarzeń na bieżąco albo wstecz.

Zdarzenie (event) opisuje fakt, że „coś się wydarzyło”: klient złożył zamówienie, kurier odebrał paczkę, czujnik zmierzył temperaturę. Kafka powstała w LinkedIn i została udostępniona jako otwarte oprogramowanie w 2011 roku. Aktualna stabilna wersja to 4.4.0 (listopad 2026).

Jak działa Kafka? Producent, broker, konsument

W Kafce biorą udział trzy role:

Najważniejsza różnica wobec zwykłego wywołania API: producent nie wie, kto jego zdarzenia czyta, i nie czeka na odpowiedź konsumentów. Usługa zamówień zapisuje zdarzenie raz, a magazyn, system faktur i wysyłka powiadomień czytają je niezależnie, każda w swoim tempie. Jeśli system faktur chwilę nie działa, po powrocie dokończy czytanie od miejsca, w którym skończył, bo zdarzenia czekają w Kafce.

Czym są topic i partycje?

Zdarzenia są uporządkowane w tematach (topics), np. zamowienia albo platnosci. Temat można porównać do folderu na zdarzenia jednego rodzaju. Dokumentacja podkreśla, że temat zawsze może mieć wielu producentów i wielu subskrybentów naraz.

Każdy temat jest podzielony na partycje (partitions), czyli „kubełki” rozłożone na różnych brokerach. Dzięki temu Kafka może przetwarzać ogromne ilości danych równolegle, bo różne partycje obsługują różne maszyny. Dwie zasady, które warto zapamiętać:

• Kolejność jest gwarantowana tylko w obrębie jednej partycji. Konsument czyta zdarzenia partycji w dokładnie tej kolejności, w jakiej je zapisano. Między partycjami nie ma gwarancji kolejności.
• Zdarzenia z tym samym kluczem trafiają do tej samej partycji. Klucz zdarzenia (event key) to np. identyfikator klienta albo pojazdu. Dzięki temu wszystkie zdarzenia jednego klienta są czytane po kolei.

Dla bezpieczeństwa dane są też kopiowane między brokerami (replikacja, replication factor). W środowisku produkcyjnym często stosuje się współczynnik 3, czyli trzy kopie.

Do której partycji trafia zdarzenie? Sprawdziłem na kluczach

Domyślnie klient Kafki liczy numer partycji z klucza: haszuje klucz i bierze resztę z dzielenia przez liczbę partycji. Sprawdziłem to bez brokera, używając funkcji haszującej murmur2 z biblioteki kafka-python. Dla trzech przykładowych kluczy:

Co z tego wynika:

• Ten sam klucz zawsze daje tę samą partycję (powtórzone klient-1 i klient-2 dały ten sam wynik), więc zdarzenia jednego klienta zachowują kolejność.
• Różne klucze mogą trafić do tej samej partycji (klient-2 i klient-3). Partycja nie oznacza „jeden klient”.
• Zmiana liczby partycji może zmienić przypisanie klucza. klient-1 po zwiększeniu z 3 do 6 partycji przeszedł z partycji 2 na 5. Jeśli zwiększysz liczbę partycji w działającym systemie, nowe zdarzenia klienta mogą trafić do innej partycji niż stare, a gwarancja kolejności dla niego na chwilę się zaburza.

To jest obliczenie algorytmu, a nie test na prawdziwym brokerze. Warto też wiedzieć, że różne biblioteki mogą liczyć partycję inaczej: według dokumentacji librdkafka (biblioteka pod confluent-kafka) domyślnie używa hasza CRC32, a zgodny z domyślnym producentem Javy jest tryb murmur2_random. Jeśli kilka usług w różnych językach zapisuje do tego samego tematu z tymi samymi kluczami, ustaw ten sam partitioner wszędzie.

Czym są offset i grupa konsumentów?

Każde zdarzenie w partycji dostaje kolejny numer, tzw. offset (offset). Konsument zapamiętuje, do którego offsetu doczytał, więc po restarcie zaczyna od właściwego miejsca. Konsumenci łączą się w grupy (consumer groups), identyfikowane przez opcję group.id:

• Różne grupy czytają niezależnie. Magazyn i system faktur to dwie grupy: każda dostaje wszystkie zdarzenia i ma własne offsety.
• W obrębie jednej grupy partycje są dzielone między konsumentów. Dzięki temu możesz uruchomić kilka kopii tej samej usługi i rozłożyć pracę. Zwykle jedna partycja jest czytana naraz przez jednego konsumenta z grupy, więc kopii powyżej liczby partycji nie ma sensu uruchamiać.

Co dzieje się, gdy nowa grupa startuje i nie ma jeszcze zapisanego offsetu? Decyduje o tym opcja auto.offset.reset: earliest zaczyna od najstarszego dostępnego zdarzenia, a latest od najnowszego (opcja none zgłasza błąd). To częsta przyczyna pytania „dlaczego mój konsument nie widzi starych wiadomości”. Domyślnie konsument zapisuje offsety automatycznie w tle (enable.auto.commit ma wartość true), co w krytycznych systemach warto świadomie zmienić na zapis po przetworzeniu zdarzenia.

Czy Kafka usuwa wiadomości po odczytaniu?

Nie, i to największa różnica wobec klasycznych kolejek. Dokumentacja mówi wprost, że w przeciwieństwie do tradycyjnych systemów wiadomości zdarzenia nie są usuwane po odczytaniu. Kafka usuwa je dopiero po upływie okresu przechowywania (retention). Domyślnie to 168 godzin, czyli 7 dni (log.retention.hours), a limit rozmiaru jest wyłączony (log.retention.bytes ma wartość -1). Dzięki temu:

• Nowa usługa może przeczytać historię zdarzeń od początku (np. po uruchomieniu nowego systemu raportowania).
• Po awarii możesz „cofnąć” offset i przetworzyć zdarzenia jeszcze raz.
• Kilka usług czyta te same dane, bez kopiowania.

Kafka czy RabbitMQ? Kafka czy Redis?

To jedno z najczęściej zadawanych pytań o Kafkę (najpopularniejsze pytanie na Stack Overflow w tym temacie dotyczy właśnie wyboru między nią a RabbitMQ). Opis poniżej jest koncepcyjny, oparty na dokumentacji, a nie na własnych pomiarach:

Zasada kciuka: jeśli chcesz wykonać zadanie raz (np. wysłać e-mail, przeskalować zdjęcie), wystarczy zwykła kolejka. Jeśli wiele systemów ma reagować na to samo zdarzenie, a Ty chcesz zachować jego historię, Kafka jest naturalniejsza. Redis służy zwykle do szybkiego cache'u i prostych struktur w pamięci, więc to inne narzędzie niż trwały dziennik zdarzeń. Małej aplikacji często nie potrzebujesz żadnego z nich: zwykła baza danych i zadania w tle wystarczą.

Czy Kafka jest szybsza od RabbitMQ? Co pokazał benchmark

Najczęściej cytowany test porównawczy opublikował w sierpniu 2020 roku Confluent, firma rozwijająca Kafkę (autorzy to inżynier Confluenta i szef projektu Apache Hudi). Przetestowano Kafkę 2.6, Pulsara 2.6 i RabbitMQ 3.8.5 na tych samych maszynach AWS z wiadomościami po 1 KB i potrójną replikacją. Wyniki, które podali autorzy:

Jak to czytać:

• Kafka wygrała przepustowością: autorzy piszą o 15 razy szybszym zapisie niż w RabbitMQ.
• RabbitMQ miał niższe opóźnienie, ale przy mniejszym obciążeniu. Autorzy zaznaczają, że jego opóźnienia pogarszają się wyraźnie powyżej 30 MB/s, więc liczby nie są porównywalne wprost.
• To test producenta jednego z systemów, z 2020 roku. Wyniki dotyczą tego sprzętu i tego obciążenia, a autorzy sami zachęcają do testów na własnych danych. Potraktuj to jako ilustrację różnicy w modelu (log na dysku kontra kolejka), a nie jako ranking na zawsze.
• Nowsze prace wskazują ten sam kierunek. Streszczenia prac z lat 2025–2026 opisują podobny wzorzec: Kafka wygrywa przepustowością, a RabbitMQ potrafi mieć niższe opóźnienie przy mniejszym obciążeniu. Nie podaję ich liczb, bo nie mogłem otworzyć pełnych tekstów, a wyniki zależą od wersji, rozmiaru wiadomości i konfiguracji.

W typowej aplikacji o zwykłym ruchu przepustowość rzadko decyduje o wyborze. Częściej decyduje model: czy zdarzenia mają zostać do ponownego odczytu i czy czyta je wiele usług.

Czy Kafka jest bazą danych?

Nie w sensie zwykłej bazy. Kafka trwale przechowuje zdarzenia, ale nie służy do wygodnego zapytania „daj mi zamówienie numer 123” jak SQL. Pytanie, czy używać jej jako magazynu zdarzeń (event store), należy do tych, które na Stack Overflow budzą dyskusje. Praktyczne podejście: Kafka niesie zdarzenia i pozwala je odtworzyć, a aktualny stan trzymasz w bazie, np. relacyjnej. O tym, jak łączyć tabele i zadawać zapytania, piszemy w artykule o relacjach i JOIN-ach w SQL.

Czy Kafka potrzebuje ZooKeepera?

Dawniej tak: do zarządzania metadanymi klastra używała zewnętrznego ZooKeepera. Własny mechanizm Kafki (KRaft) został uznany za gotowy do produkcji w wersji 3.3, a Kafka 4.0, wydana 18 marca 2025 roku, jest według ogłoszenia projektu pierwszym głównym wydaniem, które działa w całości bez ZooKeepera. Tryb KRaft jest w niej domyślny, co upraszcza wdrożenie, bo nie utrzymujesz osobnego klastra ZooKeepera. W nowych instalacjach nie stawiasz więc ZooKeepera wcale. Jeśli pracujesz ze starszym klastrem na ZooKeeperze, nie przeskoczysz po prostu do wersji 4: szczegóły migracji sprawdź w dokumentacji swojej wersji, bo ich nie weryfikowałem.

Jak wygląda kod w Pythonie? Producent i konsument

Poniżej przykład z biblioteką confluent-kafka (2.16). Scenariusz: sklep zapisuje zdarzenie o zamówieniu, a magazyn je czyta.

import json
from confluent_kafka import Producer, Consumer

producer = Producer({"bootstrap.servers": "localhost:9092"})

event = {"order_id": 123, "customer": "klient-1", "total": 199.0}
producer.produce(
    "zamowienia",
    key="klient-1",
    value=json.dumps(event),
)
producer.flush()

consumer = Consumer({
    "bootstrap.servers": "localhost:9092",
    "group.id": "magazyn",
    "auto.offset.reset": "earliest",
})
consumer.subscribe(["zamowienia"])

try:
    while True:
        message = consumer.poll(1.0)
        if message is None:
            continue
        if message.error():
            print("Błąd:", message.error())
            continue
        order = json.loads(message.value())
        print(order["order_id"], "partycja", message.partition(), "offset", message.offset())
finally:
    consumer.close()

Tego kodu nie uruchamiałem na prawdziwym brokerze. Sprawdziłem tylko to, co dało się bez niego: obiekty Producer i Consumer z taką konfiguracją tworzą się poprawnie (confluent-kafka 2.16.1, librdkafka 2.16.0), metody produce, flush, subscribe, poll i close istnieją, a literówka w nazwie opcji (np. grupa.id zamiast group.id) kończy się błędem No such configuration property. Co warto zauważyć w kodzie:

• key="klient-1" decyduje o partycji, więc wszystkie zdarzenia tego klienta trafią do jednej partycji i zachowają kolejność.
• producer.flush() czeka na wysłanie zdarzeń. Bez niego program może się zakończyć, zanim zdarzenia opuszczą bufor.
• group.id i auto.offset.reset to dwie opcje, o których pisałem wyżej: pierwsza wskazuje grupę, druga mówi, od czego zacząć, gdy nie ma zapisanego offsetu.
• consumer.close() w finally pozwala poprawnie opuścić grupę, żeby partycje szybko przejął inny konsument.

Jeśli chcesz uruchomić to u siebie, potrzebujesz działającego brokera Kafki (instrukcja uruchomienia znajduje się w dokumentacji Apache Kafka) i adresu w bootstrap.servers.

Kto używa Kafki i z jakimi technologiami się ją łączy?

Strona projektu Apache Kafka twierdzi, że z Kafki korzysta ponad 80% firm z listy Fortune 100 oraz tysiące innych organizacji. To dane deklarowane przez sam projekt, bez podania źródła pomiaru, więc traktuj je jako orientacyjne. Wiarygodniejsze są konkretne wpisy z oficjalnej listy „Powered By”, w których firmy same opisują, do czego Kafka im służy. Kilka znanych przykładów:

Wszystkie wpisy opisują podobne zastosowania: zbieranie zdarzeń i logów, analitykę w czasie rzeczywistym, integrację usług i synchronizację danych. To lista dobrowolna i może być nieaktualna, więc nie jest rankingiem popularności.

Z jakimi technologiami łączy się Kafkę? Według strony projektu moduł Kafka Connect integruje ją z setkami źródeł i odbiorców zdarzeń, m.in. z bazą Postgres, systemem JMS i wyszukiwarką Elasticsearch. W opisach firm na liście „Powered By” często pojawiają się też narzędzia analityczne i do przetwarzania strumieni, takie jak Hadoop, Storm i Splunk, a także Kafka Streams, czyli biblioteka do przetwarzania zdarzeń w aplikacji. Dla programisty ważne jest to, że Kafkę zwykle łączy się z językiem, w którym piszesz backend: oficjalnym klientem jest biblioteka Javy, a w Pythonie używa się np. confluent-kafka, którą pokazuję wyżej. Nie sprawdzałem, które języki i frameworki najczęściej współpracują z Kafką w polskich firmach.

Kiedy potrzebujesz Kafki, a kiedy nie?

Kafkę możesz też uruchomić jako usługę zarządzaną u dostawców chmury, np. Confluent Cloud albo Amazon MSK, zamiast utrzymywać własny klaster. Nie podaję ich cen i funkcji, bo ich nie sprawdzałem.

Czy Kafka pojawia się w ofertach pracy?

Sprawdziłem to 5 listopada 2026 na portalu justjoin.it, wpisując słowo kluczowe w wyszukiwarkę:

Oferta ze słowem „kafka” to więc około 7% wszystkich ofert na tym portalu. Trzeba to czytać ostrożnie: nie wiem dokładnie, jak portal dopasowuje słowo kluczowe (w tytule, tagach czy opisie), a pojedynczy pomiar z jednego dnia niczego nie mówi o trendzie. Nie nadaje się też do porównań z innymi technologiami, bo dla frazy „react” ta sama wyszukiwarka pokazała 1 297 ofert, co przy popularności Reacta wygląda na zaniżone. To dlatego nie podaję rankingu technologii. Z przeglądu pierwszych wyników dla „kafka” wynika jeszcze jedno: wśród nich były stanowiska wprost kafkowe (Kafka SRE, Kafka Engineer, Kafka Platform Engineer), więc część ofert szuka specjalisty od samej platformy, a nie programisty, który „zna Kafkę z projektu”. Nie mam danych, ilu z tych ofert dotyczy stanowisk juniorskich, więc przed nauką Kafki sprawdź, jak wygląda oferta na poziom, którego szukasz.

Jak zacząć naukę Kafki?

1. Opanuj backend. Kafka ma sens, gdy masz kilka współpracujących usług. Zacznij od jednej aplikacji z bazą danych, np. pierwszego API we FastAPI.
2. Zrozum pojęcia na papierze: zdarzenie, temat, partycja, offset, grupa konsumentów. Narysuj sobie sklep z trzema usługami czytającymi te same zamówienia.
3. Uruchom Kafkę lokalnie według instrukcji w dokumentacji i wyślij pierwsze zdarzenie z Pythona.
4. Eksperymentuj z kluczami i grupami: uruchom dwóch konsumentów w jednej grupie i obserwuj, jak dzielą partycje.
5. Sprawdź, jak Kafka jest używana w ofertach, które Cię interesują, zanim poświęcisz jej tygodnie. W wielu projektach wystarczy znać podstawy.

Jeśli chcesz zbudować solidny fundament backendowy w Pythonie pod okiem mentora, zapraszam na kurs Python developer. Kafka nie jest jego elementem, ale to, czego nauczysz się o API, bazach danych i architekturze aplikacji, jest punktem wyjścia do pracy z systemami zdarzeniowymi.

Na co zwraca uwagę mentor przy Kafce?

Zanim dodasz Kafkę do projektu, zapytaj, czy wystarczy Ci zwykła kolejka zadań. Kafka ma sens, gdy kilka usług musi reagować na to samo zdarzenie albo gdy chcesz odtworzyć jego historię, a w małej aplikacji to zwykle zbędna komplikacja.

Podsumowanie

• Apache Kafka to rozproszona platforma do zapisu, przechowywania i odczytu strumieni zdarzeń, w której producenci zapisują, a konsumenci czytają niezależnie.
• Zdarzenia trafiają do tematów podzielonych na partycje; kolejność jest gwarantowana w obrębie partycji, a zdarzenia z tym samym kluczem trafiają do jednej partycji.
• Offset pamięta, dokąd doczytał konsument, a grupa konsumentów dzieli pracę między kopie usługi.
• Zdarzenia nie znikają po odczytaniu, tylko po okresie retencji (domyślnie 7 dni).
• Kafka różni się od kolejki typu RabbitMQ tym, że zdarzenia można czytać wielokrotnie i przez wiele grup; w benchmarku Confluenta z 2020 roku wygrała przepustowością, a RabbitMQ miał niższe opóźnienie przy mniejszym obciążeniu. W małej aplikacji zwykle żadne z nich nie jest potrzebne.
• Od wersji 4.0 (marzec 2025) Kafka działa bez ZooKeepera, w trybie KRaft.
• Na justjoin.it słowo „kafka” pojawiało się 5 listopada 2026 w 1 418 z 20 393 ofert, ale to pojedynczy pomiar o niejasnym sposobie dopasowania.
• Przykłady w Pythonie sprawdziłem tylko pod kątem konfiguracji i przypisania klucza do partycji, bez prawdziwego brokera.