Valós idejű cikkelosztás 12 csatornán: nyolc másodperc end-to-end

Tavaly nyáron még 90–120 másodperc telt el a 'publish' gomb és aközött, hogy a cikk megjelent az utolsó disztribúciós csatornán. Ma 8 másodperc alatt 12 csatornán van kint. Nem azért, mert gyorsabban várunk — azért, mert szétszedtük a monolitot.

Mi az a 12 csatorna

Web (kanonikus URL), AMP, RSS, főoldal-cache, kategória-cache, Apple News, Google News, Facebook IA, Telegram-csatorna, e-mail-hírlevél (instant alert sávban), push notification (mobil app), és OG-előnézet (Open Graph image + meta). A 12-est nem mi találtuk ki — ez ma egy magyar online sajtóorgánum minimum-elosztási spektruma, ha komolyan veszi az olvasói elérést.

A séma-per-csatorna transzformer

Minden cikk egy belső JSON-reprezentációban él, amit kanonikus shape-nek hívunk. Tizenkét transzformer fut rajta, mindegyik más csatorna formátumát adja vissza. Az Apple News-é deklaratív, az AMP-é HTML5-szublimitt, a Telegrámé Markdown-ish szöveg, az OG-előnézet 1200×630 PNG, és így tovább. A transzformerek tiszta függvények — adott bemenetre adott kimenet. Egységtesztelhetők, párhuzamosan futtathatók, sem közös állapotuk, sem közös függőségük.

OG-image cache warming

Az Open Graph-kép Vercel @vercel/og-vel generálódik, de nem azon a kérésen, amikor először kérik. A publish pillanatában a fan-out worker triggereli a generálást, és előre felmelegíti a Cloudflare edge cache-t a négy leggyakoribb régiónk POP-jaiban (Frankfurt, London, Amsterdam, Madrid). Mire az első Twitter/X bot lekéri az OG-t — tipikusan 3–5 másodperccel a publish után — már cache-hit van. Ezt akkor vezettük be, amikor rájöttünk, hogy a 'lassú vagyok az X-en, mert nem mutat előnézetet az első órában' panaszok mind a cold-start OG-generálásra vezethetők vissza.

Fan-out BullMQ-val

A 12 csatorna 12 különálló BullMQ-queue. Mindegyiknek saját concurrency-limitje, saját retry-stratégiája, saját dead-letter queue-ja. A publish endpoint csak annyit csinál, hogy enqueue-l 12 jobot és visszatér. A munkások párhuzamosan dolgozzák fel — a leglassabb a Google News (1.5–4s, mert az ő ingest API-juk poll-alapú visszajelzést használ), a leggyorsabb a főoldal-cache invalidáció (50–80ms, mert a saját CDN-ünkön belül van).

End-to-end mediánunk 8 másodperc, p95 12 másodperc, p99 26 másodperc. A p99 mindig a Google News.

A 22 perces leállás

Egy hónapja a Cloudflare egy közlemény nélküli cache-key-formátumváltást vezetett be a Vary header kezelésére az enterprise tier-en. A mi OG-cache warm-up logikánk a régi key-formátumra épült. Eredmény: 22 percig minden új cikk OG-előnézete cold-start cache-miss-be futott, ami önmagában még csak lassúság — de a fan-out worker timeout-ja 15 másodperc volt, ami alatt egy cold OG-generálás 800ms-os Inter-betűtöltéssel és 1200×630 SSR rendereléssel nem mindig fért bele. Eredmény: timeout-ok, retry-ok, queue-túlcsordulás.

A javítás 22 perc volt: cache-key normalizálás a saját oldalunkon, plusz worker timeout 30s-re. A tanulság hosszabb: minden külső infra-szolgáltató 'csendes' változtatást fog csinálni, és a saját timeout-jaink legyenek nagyvonalúak.

Mit nem oldottunk meg

A csatorna-specifikus szerkesztési visszairány — például az Apple News editorial javasolja egy másik főképet — nem érkezik vissza a CMS-be. Ezt manuálisan oldjuk meg, e-mailes copy-paste szinten. Tűrhető, de szégyellnivaló. A következő félév roadmapjén szerepel.

Részleges sikerek reconciliációja

A második megoldatlan probléma a részleges publikálás-reconciliáció. Ha a fan-out hatos csatornája sikeres, de a hetedik dead-letter-be került, ma nincs olyan szerkesztőségi felület, amely közli a kollégákkal, hogy 'tizenegy a tizenkettőből kint van, itt az egy, ami nem'. Ma ez Grafana-dashboardokon él, amit egyetlen szerkesztő sem olvas. A helyes felület a CMS-en belül van, nem az observability-stack-ben. A 2026 második félévi roadmap-on ez van az első helyen, mert egy hét alatt kétszer hallottunk arról, hogy a Telegram-csatornánkról egy órán át hiányzott egy frissen publikált cikk anélkül, hogy bárki észrevette volna a szerkesztőségben.