Architektura skali vs. Architektura czasu
Jako inżynierowie przyzwyczailiśmy się myśleć, że systemy informatyczne działają w czasie rzeczywistym. W przypadku gigantów takich jak Grupa OLX (właściciel Otodom), skala działania wymusza jednak pewne kompromisy architektoniczne.
Użytkownik końcowy widzi prosty interfejs: „Dodaj ogłoszenie” -> „Wyślij powiadomienie”.
Pod maską jednak proces ten jest znacznie bardziej złożony i – co kluczowe dla szukającego mieszkania – nie jest natychmiastowy.
W tej analizie rozłożymy na czynniki pierwsze drogę, jaką pokonuje ogłoszenie od kliknięcia „Publikuj” do pojawienia się na Twoim telefonie, i wyjaśnimy, dlaczego standardowe aplikacje zawsze będą wolniejsze od dedykowanych monitorów typu LZX.
Problem 1: Caching i propagacja danych
Pierwszym wąskim gardłem jest warstwa prezentacji danych. Serwisy obsługujące miliony zapytań na sekundę nie pobierają danych bezpośrednio z głównej bazy (Master DB) przy każdym odświeżeniu strony przez użytkownika. Byłoby to zabójcze dla wydajności.
Zamiast tego stosuje się agresywny caching (CDN, Redis).
Kiedy ogłoszenie trafia do systemu, musi zostać zindeksowane i rozpropagowane na serwery brzegowe.
- Efekt: Ogłoszenie może być widoczne dla osoby, która ma bezpośredni link (lub dla bota skanującego API), ale nie być jeszcze widoczne na listingu wyszukiwania (Search Index) przez kilka minut.
Problem 2: Batch Processing (Przetwarzanie wsadowe)
To tutaj powstaje główne opóźnienie. Systemy powiadomień (e-mail, push) dla milionów użytkowników nie działają w modelu Event-Driven (zdarzenie -> natychmiastowa reakcja) dla każdego pojedynczego subskrybenta. Działają w oparciu o kolejki i harmonogramy (Cron Jobs).
Algorytm w uproszczeniu wygląda tak:
- Agregacja: System zbiera nowe ogłoszenia z ostatnich X minut (np. 15, 30, 60 min).
- Dopasowanie: Uruchamiany jest proces
matchowaniaogłoszeń do zapisanych kryteriów użytkowników. - Wysyłka: Kolejka powiadomień trafia do serwera wysyłkowego (SMTP / FCM).
Dla platformy, wysłanie 100 000 maili w jednej paczce co godzinę jest tańsze i bezpieczniejsze (mniejsze ryzyko zablokowania przez filtry antyspamowe) niż wysyłanie pojedynczych wiadomości co sekundę.
Wniosek: Otrzymujesz powiadomienie o 10:45, które zawiera ogłoszenia dodane między 10:00 a 10:40. Dla systemu to optymalizacja. Dla Ciebie – stracona szansa.
Zobacz, jak wykorzystać tę wiedzę w praktyce w naszym poradniku: Jak wynająć mieszkanie…
Analiza porównawcza: Otodom vs LZX (Low Latency Monitor)
Przeprowadziliśmy test polegający na monitorowaniu konkretnych parametrów (np. „Mieszkanie, Warszawa, Mokotów, < 3000 PLN”) jednocześnie trzema metodami.
Oto uśrednione wyniki czasów reakcji (Time-to-Alert):
| Zdarzenie | Czas rzeczywisty | Oficjalna Aplikacja | LZX.pl |
| Publikacja ogłoszenia | T0 (00:00) | – | – |
| Indeksacja w wyszukiwarce | T+2 min | – | T+3 min (Alert) |
| Przetwarzanie kolejki Push | T+30 min | – | – |
| Dostarczenie powiadomienia | T+45 min | T+45 min (Alert) | – |
Delta (Różnica): 42 minuty.
W świecie nieruchomości w dużych miastach, 40 minut to czas, w którym wykonano już 3-5 telefonów do właściciela.
Dlaczego LZX jest szybszy?
LZX nie jest platformą ogłoszeniową. Nie musi obsługiwać uploadu zdjęć, płatności czy moderacji treści.
Nasza architektura skupia się wyłącznie na odczycie (Read-Heavy).
Działamy jak Twój dedykowany crawler. Nie czekamy, aż serwis „wypchnie” do nas dane (Push). My aktywnie „pytamy” serwis o zmiany (High-Frequency Polling) w krótkich odstępach czasu. Dzięki temu omijamy kolejkę przetwarzania wsadowego platformy matki.
Podsumowanie: Przewaga dzięki technologii
Korzystanie z oficjalnych powiadomień w 2026 roku przypomina grę na giełdzie z opóźnionymi o godzinę notowaniami. Jest darmowe, wygodne, ale nieskuteczne w starciu z profesjonalistami.
Jeśli szukasz mieszkania w obleganej lokalizacji, musisz zniwelować opóźnienie systemowe. LZX to narzędzie, które sprowadza proces wyszukiwania z poziomu „batch” do poziomu „near real-time”.