Mechanizm strumieniowania wiadomości nierzadko stanowi nieodzowny element infrastruktury w systemach rozproszonych. Od klasycznej integracji za pomocą zdarzeń (event-driven architecture) w architekturze mikroserwisowej, po zaawansowane systemy tradingowe typu HFT oparte na podejściu low latency — niezawodna (i możliwie szybka) komunikacja pomiędzy niezależnymi aplikacjami ma krytyczne znaczenie dla poprawnego działania systemu.
Jak wygląda message streaming od podstaw? Z jakimi wyzwaniami musi zmierzyć się inżynier oprogramowania rozwijający takie narzędzie? Skąd bierze się przepustowość rzędu milionów wiadomości na sekundę? Jak duży wpływ może mieć kernel Linuxa na wydajność takiego rozwiązania?
Chciałbym podzielić się swoim doświadczeniem, gdzie po kilku latach pracy w sektorze “tradingowym”, zdecydowałem się na dogłębne poznanie mechanizmu strumieniowania komunikatów właśnie poprzez rozwój własnego “message streamingu” od zera.
Iggy.rs — projekt, który oryginalnie miał posłużyć do nauki języka programowania w Rust, z czasem trafił na listę GitHub Trending, zyskał kilkunastu stałych kontrybutorów, posiada całkiem pokaźny ekosystem i powoli zyskuje coraz większą popularność. To dzięki pracy nad nim, zrozumiałem m.in. dlaczego projektanci takich narzędzi jak choćby Kafka podjęli takie, a nie inne decyzje i jak duże znaczenie na stabilność, niezawodność oraz wydajność ma faktyczne zrozumienie mechanizmów synchronizacji danych, I/O, oraz niskopoziomowych API na poziomie konkretnego systemu operacyjnego.