🛠️ Nejdůležitější backend novinky 05.04.-12.04.2026
Backend vývoj novinky 🛠️
05.04.-12.04.2026
Bloom filtry v Go: jak zrychlit negativní dotazy a ulevit backendu
Článek ukazuje, jak Bloom filtr funguje jako rychlá paměťová brána před drahými dotazy do cache nebo úložiště. V popsané doporučovací službě, kde 97–98 % kontrol bylo negativních, nasazení Bloom filtru výrazně omezilo zbytečné I/O a zlepšilo odezvu. Autor vysvětluje princip falešně pozitivních výsledků, volbu velikosti filtru a počtu hashovacích funkcí i praktickou implementaci v Go. Hlavní pointa je jednoduchá: když je většina dotazů negativních a ověření je drahé, Bloom filtr umí výrazně snížit latenci i náklady.
- Pro backend je klíčové, že Bloom filtr nikdy nevytváří falešně negativní výsledek: pokud vrátí „není přítomno“, není potřeba sahat do vzdáleného úložiště a šetří se síť i čtení.
- V uvedeném provozu klesla p95 latence zhruba ze 140 ms na 96 ms, počet přesných kontrol z asi 120 na 24 na požadavek a čtecí zátěž backendu o 65–70 %.
- Go se pro tuto techniku hodí díky jednoduché práci s bity a předvídatelnému výkonu, ale v praxi rozhoduje hlavně správné ladění parametrů m a k, kvalita hashovacích funkcí a průběžné sledování saturace filtru.
Mechanická sympatie: jak psát software, který lépe využije moderní hardware
Článek shrnuje principy takzvané mechanické sympatie, tedy návrhu softwaru s ohledem na to, jak skutečně fungují CPU, cache a paměť. Hlavní myšlenka je jednoduchá: výkon často nezvyšuje jen rychlejší hardware, ale hlavně správný přístup k datům, vláknům a sdíleným zdrojům. Mezi klíčové zásady patří předvídatelný sekvenční přístup do paměti, práce s cache line, princip jediného zapisovatele a přirozené dávkování požadavků. Tyto postupy se hodí od nízkolatenčních služeb až po AI inference servery nebo datové pipeline.
- Sekvenční a předvídatelný přístup k datům bývá výrazně rychlejší než náhodné čtení z paměti, takže se vyplatí volit algoritmy a datové struktury, které minimalizují skoky po paměti a práci po jednotlivých klíčích.
- Ve vícevláknových aplikacích je častým zdrojem zpomalení false sharing a zámky nad sdílenými zapisovatelnými daty; lepší výsledek často přinese oddělení dat do samostatných cache line a model s jedním vláknem, které provádí všechny zápisy.
- Pro backendy a AI služby je praktický vzor actoru s asynchronní frontou a přirozeným batchingem: požadavky se zpracují hned, jak jsou k dispozici, a dávka se uzavře při zaplnění nebo vyprázdnění fronty, což snižuje latenci i režii oproti čekání na pevný interval.
Istio rozšiřuje service mesh pro AI: přidává multicluster ambient režim a řízení inference
CNCF představila výrazný posun ve vývoji Istia, které se nově víc zaměřuje na provoz AI workloadů v Kubernetes. Novinka přináší beta podporu ambient režimu napříč více clustery, rozšíření Gateway API pro inference a experimentální integraci agentgateway. Cílem je zjednodušit provoz service meshe, omezit režii kolem sidecar proxy a zároveň lépe řídit dynamický provoz spojený s AI modely a agenty. Istio se tak posouvá od klasického síťování mikroslužeb k platformní vrstvě pro distribuované a latenci citlivé aplikace.
- Ambient multicluster umožní spravovat provoz, bezpečnost a observabilitu napříč více clustery bez tradiční sidecar architektury, což může výrazně zjednodušit provoz i škálování backendových platforem.
- Gateway API Inference Extension přenáší směrování AI inference přímo do Kubernetes-native rozhraní, takže týmy mohou řídit AI požadavky stejnými mechanismy jako běžný aplikační provoz.
- Pro praxi to znamená méně vlastní integrační logiky a menší roztříštěnost nástrojů: část funkcí pro traffic management, policy a observabilitu AI workloadů se přesouvá přímo do service meshe.
Cloudflare chce mít do roku 2029 plně postkvantově zabezpečené i ověřování
Cloudflare zrychluje svůj plán přechodu na postkvantovou kryptografii a nově míří na rok 2029, kdy chce mít zabezpečené nejen šifrování, ale i autentizaci. Důvodem jsou nové výzkumy a odhady, podle nichž by kvantové počítače mohly prolomit dnes běžně používané algoritmy jako ECC nebo RSA dřív, než se čekalo. Firma upozorňuje, že největší riziko už není jen budoucí dešifrování zachycených dat, ale hlavně možnost padělat klíče, certifikáty a přístupy. Právě proto teď považuje přechod na postkvantové ověřování za vyšší prioritu než samotnou ochranu proti útokům typu „ulož teď, dešifruj později“.
- Pro backend a infrastrukturu to znamená začít řešit hlavně dlouhodobé klíče: TLS certifikáty, podepisování aktualizací, API klíče, přístupové tokeny i interní autentizační mechanismy.
- Nestačí jen přidat podporu postkvantových algoritmů; kvůli downgrade útokům je potřeba postupně vypnout zranitelné varianty a po migraci rotovat dříve vystavené tajné údaje.
- Cloudflare tvrdí, že většinu svých služeb už má chráněnou postkvantovým šifrováním, ale úplná bezpečnost bude vyžadovat i připravenost prohlížečů, aplikací, origin serverů a dodavatelského řetězce, což je práce na roky.
GitHub Actions spouští vlastní obrazy runnerů v ostrém provozu
GitHub zpřístupnil vlastní obrazy pro hostované runnery v GitHub Actions v režimu General Availability. Týmy si tak mohou připravit runner s předinstalovanými nástroji, runtime prostředími, certifikáty i interními binárkami a omezit opakované nastavování při každém běhu CI. Výsledkem jsou rychlejší pipeline a menší režie u složitějších buildů. Funkce je ale dostupná jen pro větší runnery v placených tarifech Team a Enterprise Cloud.
- Pro backend týmy to znamená hlavně kratší časy jobů: místo opakované instalace Node.js, Pythonu, SDK nebo interních závislostí se vše připraví jednou do obrazu a další běhy už startují hotové.
- Obrazy se verzují automaticky při každém úspěšném vytvoření, lze je připnout na konkrétní verzi nebo nechat runner přebírat nejnovější vydání; dává to větší kontrolu nad stabilitou i zaváděním aktualizací.
- Je potřeba počítat se správou dalšího artefaktu: GitHub doporučuje obrazy pravidelně obnovovat kvůli bezpečnostním opravám, přístup i retenční politiky se řídí v nastavení Actions a vše zůstává uvnitř ekosystému GitHubu.
Uber rozdělil Hive sklad na federaci a přesunul 16 tisíc datasetů bez výpadků
Uber přepracoval svůj Hive datový sklad z jednoho centrálního prostředí na federovanou architekturu, která spravuje přes 16 000 datasetů a více než 10 PB dat. Cílem bylo odstranit limity monolitického řešení, jako byly výpadky šířící se napříč systémy, přetížení sdílených prostředků a slabší řízení přístupů. Klíčem k migraci byl přístup založený na přesměrování ukazatelů v Hive Metastore, takže nebylo nutné kopírovat petabajty dat při každém přesunu. Díky tomu běžely analytické úlohy i pipeline pro strojové učení po celou dobu bez odstávky.
- Pro backend a datové platformy je nejzajímavější pointer-based migrace: dataset se jednou přesune do nového umístění v HDFS a následně se v Hive Metastore jen atomicky přepne odkaz, což minimalizuje riziko i dobu zásahu.
- Architekturu podpírají čtyři části: Bootstrap Migrator, Realtime Synchronizer, Batch Synchronizer a Recovery Orchestrator, které zajišťují průběžnou synchronizaci metadat, ověřování kontrolními součty a bezpečný rollback při problému.
- Federace přinesla lepší škálování po doménách, přísnější ACL a menší závislost na centrálním týmu; Uber uvádí přes 7 milionů synchronizací v HMS a uvolnění více než 1 PB úložiště odstraněním zastaralých dat.
Google Cloud posouvá PostgreSQL v replikaci, upgradu i stabilitě jádra
Google Cloud shrnul své příspěvky do jádra PostgreSQL z druhé poloviny roku 2025, které míří hlavně na logickou replikaci, spolehlivější upgrady a vyšší odolnost databáze. Nejviditelnější novinkou je automatická detekce konfliktů při replikaci, důležitá pro scénáře s aktivně zapisujícími uzly. Přibyly také úpravy kolem sekvencí, oprav deadlocků a zrychlení nástroje pg_upgrade u velkých nasazení. Vedle toho vývojáři opravili několik chyb v práci s WAL, indexy a rozšířeními.
- Pro backend týmy je klíčová automatická detekce konfliktů v logické replikaci, která snižuje ruční zásahy a usnadňuje provoz více zapisujících uzlů.
- Replikace nově lépe pokrývá i sekvence a pg_upgrade zvládá efektivněji velké objekty, takže migrace a verze databáze mohou být rychlejší a méně rizikové.
- Opravy kolem self-deadlocků, uchování WAL během upgradu, diagnostiky poškozených indexových stránek a načítání rozšíření zvyšují provozní stabilitu PostgreSQL v produkci.
CNCF zpřístupní projektům nástroj Kusari Inspector pro bezpečnější software supply chain
CNCF navázala spolupráci s firmou Kusari, která poskytne projektům hostovaným pod CNCF zdarma svůj nástroj Kusari Inspector pro zabezpečení dodavatelského řetězce softwaru. Ten kombinuje analýzu závislostí s asistovanou kontrolou kódu a pomáhá odhalovat rizika i v nepřímých závislostech, které bývají pro maintainery špatně viditelné. Cílem je dostat bezpečnost přímo do vývojového workflow a zachytit problémy už během pull requestů. Iniciativa reaguje na rostoucí složitost cloud-native projektů i častější útoky přes balíčky, původ artefaktů a slabou dohledatelnost závislostí.
- Pro backend týmy je klíčové, že nástroj mapuje přímé i transitivní závislosti, upozorňuje na mezery v provenienci a atestacích a dává vývojářům kontext přímo v pull requestech.
- Menším open source týmům může spolupráce výrazně ušetřit čas, protože místo roztříštěných bezpečnostních nástrojů získají jednotnější pohled na rizika a snadnější prioritizaci oprav.
- Řešení zapadá do širšího ekosystému kolem SLSA, GUAC, in-toto a OpenVEX a ukazuje posun od jednorázového skenování ke průběžně vynucované bezpečnosti software supply chain.
Jak udržet frontu v Postgresu bez zpomalování celé databáze
Článek ukazuje, že největší problém front nad Postgresen není samotný výkon zpracování úloh, ale úklid „mrtvých“ řádků po DELETE operacích. Když VACUUM nestíhá nebo ho blokují dlouhé či překrývající se transakce z jiných workloadů, roste indexový i tabulkový balast a fronta postupně zpomaluje. Moderní Postgres situaci zlepšil díky SKIP LOCKED a lepší správě B-tree indexů, ale základní problém MVCC tím nezmizel. Řešením je hlídat, aby pomalejší analytické dotazy nedržely MVCC horizont příliš dlouho a nebránily průběžnému úklidu.
- Pro backend praxi je klíčové držet transakce workerů co nejkratší a používat vzor
FOR UPDATE SKIP LOCKED, aby více workerů nebralo stejné úlohy a fronta se zpracovávala paralelně. - Samotné timeouty jako
statement_timeoutnebotransaction_timeoutnestačí, protože neumí omezit souběh pomalých dotazů, které průběžně blokují VACUUM a tím zhoršují latenci celé fronty. - V testu pomohlo až cílené omezení analytických dotazů podle typu provozu: přiškrcení jejich souběhu udrželo frontu stabilní i při vysoké zátěži, zatímco bez toho vznikala fronta úloh, rostly dead tuples a lock time šel do stovek milisekund.
Etsy převedlo vlastní MySQL shardování o 1 000 shardech na Vitess
Etsy po několika letech dokončilo migraci své rozsáhlé MySQL infrastruktury na Vitess, který nově řídí směrování dotazů i mapování dat mezi shardy. Místo kompletního přesunu dat firma vytvořila vlastní vindexy, aby do Vitess přenesla stávající shardovací logiku bez rizikového a zdlouhavého re-shardingu. Výsledkem je odstranění centrální neshardované „index“ databáze, menší složitost pro vývojáře a lepší podpora budoucího škálování. Celá migrace se týkala prostředí s 425 TB dat, zhruba 1 000 shardy a provozem kolem 1,7 milionu požadavků za sekundu.
- Klíčový technický krok bylo nasazení vlastních vindexů ve Vitess, které zachovaly existující pravidla shardování a umožnily migraci bez okamžitého přerozdělení všech dat.
- Pro backend týmy je zásadní, že Vitess skrývá shardovací logiku před aplikací, takže vývojáři už nemusí ručně řešit, na který shard dotaz míří.
- Architektura se tím posunula od pomalých a ručních operací k prostředí, které lépe podporuje resharding i rozdělení dosud neshardovaných tabulek, a zároveň odstraňuje dřívější single point of failure.
Ještě nemáte odběr?
Nenechte si utéct žádnou důležitou novinku. Přidejte se k nám a získejte pravidelný informační přehled čistých faktů přímo do své schránky.