🛠️ Nejdůležitější backend novinky 19.07.-26.07.2026
Backend vývoj novinky 🛠️
19.07.-26.07.2026
PostgreSQL outbox zpřehledňuje a zajišťuje odesílání registračních e-mailů
Článek doporučuje ukládat záměr odeslat ověřovací e-mail do PostgreSQL ve stejné transakci jako vytvoření uživatele a tokenu, místo přímého publikování do fronty v rámci HTTP požadavku. Tím se výrazně snižují problémy při výpadcích mezi API, databází a workerem, například když se účet vytvoří, ale e-mail se nezařadí k odeslání. Klíčovou roli hraje unikátní deduplikační klíč, který brání dvojímu zařazení stejného e-mailu při opakování požadavku. Worker pak bezpečně zpracovává čekající záznamy z outboxu a mění jejich stav na odeslaný nebo chybný.
- Pro backend je nejdůležitější, že zápis uživatele, tokenu a outbox záznamu proběhne atomicky v jedné transakci, takže po potvrzení transakce existuje trvalý důkaz, že e-mail měl být odeslán.
- Deduplikační klíč typu
signup:pomáhá udržet API idempotentní a chrání před duplicitními uvítacími nebo ověřovacími e-maily při retry požadavků. - Prakticky se hodí vracet z API stav typu „doručení naplánováno“ a interní identifikátory pro dohledání, zatímco worker může číst dávky přes
FOR UPDATE SKIP LOCKED, což usnadňuje debugging, staging i pozdější škálování.
DoorDash postavil transparentní proxy cache na Envoy a Valkey pro 1,5 milionu požadavků za sekundu
DoorDash nasadil platformu Entity Cache, která zachytává HTTP a gRPC volání v service meshi a obsluhuje často čtená, málo se měnící odpovědi přímo z cache bez úprav aplikačního kódu. Řešení běží nad Envoy a Valkey, podporuje přes 100 endpointů v 50 službách a dosahuje dostupnosti 99,99999 %. Cílem je snížit zbytečné volání mezi mikroslužbami, odlehčit backendům a omezit špičky latence. Při výpadku upstreamu umí systém dočasně vracet mírně zastaralá, ale stále platná data místo úplného selhání.
- Pro backend týmy je klíčové, že cache je přesunuted do infrastrukturní vrstvy: služby dál posílají stejné požadavky a chování cache se řídí centrálně přes service mesh, bez duplikace logiky v jednotlivých aplikacích.
- Spolehlivost zajišťuje invalidace řízená událostmi přes Kafka, dvojí TTL pro obsluhu výpadků a automatické vyřazení nezdravých cache instancí v Envoy, takže systém drží provoz i při delších incidentech.
- Výkonnostní optimalizace jako lock-free single-flight, vlastní buffer pooly a předčasné obnovování podle algoritmu XFetch přinesly 5× vyšší propustnost na pod, o 50 až 60 % méně alokací, až 80 % nižší špičky P99 latence a více než 90% cache hit rate.
Cloudflare zpřístupnil Internal DNS v ostrém provozu pro firemní zákazníky
Cloudflare uvedl Internal DNS do obecné dostupnosti jako sjednocenou službu pro interní i veřejné DNS na jedné platformě. Řešení kombinuje autoritativní i rekurzivní DNS, zjednodušuje split-horizon scénáře a napojuje interní jmenné rozlišení na Zero Trust politiky v Cloudflare Gateway. Změny se šíří přes stejnou API vrstvu jako běžné DNS záznamy, takže se dají spravovat přes dashboard, API i Terraform. Pro Enterprise zákazníky používající Cloudflare Gateway je služba dostupná bez příplatku.
- Provozní přínos je hlavně v konsolidaci: veřejné i privátní DNS, politiky, audit i logy běží v jednom řídicím rozhraní místo několika oddělených systémů.
- Pro backend a infrastrukturu je důležité, že interní zóny, DNS pohledy a resolver politiky lze spravovat programově přes API a Terraform, bez ruční synchronizace duplicitních konfigurací.
- V praxi to pomáhá nahradit staré DNS appliance a cloudově uzamčené resolvery, přičemž interní jména mohou fungovat napříč pobočkami, datacentry, cloudy i vzdálenými uživateli přes stejnou Cloudflare síť.
Node.js chystá bezpečnostní aktualizace pro řady 26.x, 24.x a 22.x
Node.js 27. července 2026 vydá nebo krátce poté zpřístupní nové bezpečnostní verze pro větve 26.x, 24.x a 22.x. Nejzávažnější opravená zranitelnost má ve všech těchto řadách hodnocení HIGH. Projekt zároveň připomíná, že ukončené verze jsou při podobných bezpečnostních vydáních standardně považovány za zasažené. Provozovatelé by proto měli co nejdřív přejít na podporovanou a aktuální verzi podle oficiálního harmonogramu vydání.
- Pokud provozujete služby na Node.js 22.x, 24.x nebo 26.x, vyplatí se připravit rychlé nasazení záplat do produkce i testovacích prostředí.
- Aplikace běžící na verzích po konci životního cyklu mají zvýšené riziko, protože při bezpečnostních opravách už nejsou aktivně kryté standardní podporou.
- Pro backend týmy je to signál zkontrolovat inventář runtime verzí, CI/CD pipeline i plán aktualizací, aby se bezpečnostní release dostal do provozu bez zbytečného zdržení.
AWS ukázalo aktivně-aktivní architekturu pro odolné CloudFormation Custom Resources napříč regiony
AWS popsalo referenční návrh, jak provozovat CloudFormation Custom Resources ve více regionech bez výpadku a bez dvojího zpracování stejné události. Řešení stojí na rozeslání události přes SNS do dvou regionů, zpracování přes SQS a Lambda a koordinaci pomocí DynamoDB Global Tables. Primární region zpracovává požadavek hned, sekundární s řízeným zpožděním převezme práci jen při selhání nebo nedokončení. Automatický failover hlídají CloudWatch a Amazon Application Recovery Controller.
- Pro backend a IaC praxi je klíčové, že návrh řeší chybějící nativní multi-region podporu v CloudFormation: přidává distribuovaný zámek, idempotenci a kontrolu stavu požadavků.
- Architektura snižuje riziko duplicitních vedlejších efektů, například opakovaného volání externího API, dvojitého zápisu do databáze nebo chybného spuštění workflow při Create, Update a Delete operacích.
- Vzor se hodí hlavně pro kritické nasazení s požadavky na disaster recovery, vysokou dostupnost a geografickou odolnost, kde by jednorégionový Lambda handler představoval nepřijatelný bod selhání.
Prompt injection v GitHub AI agentovi umí vytáhnout data ze soukromých repozitářů
Výzkumníci z Noma Security ukázali útok s názvem GitLost, který zneužívá GitHub Agentic Workflows k úniku citlivých dat do veřejných komentářů. Stačí založit issue ve veřejném repozitáři organizace, jejíž AI agent má přístup i k dalším, včetně privátních repozitářů. Skryté instrukce v textu issue dokážou obejít ochrany modelu a přimět ho přečíst neveřejný obsah a zveřejnit ho. Případ ukazuje, že u agentních systémů už nestačí spoléhat jen na klasické hranice přístupů a oprávnění.
- Pro backend a DevOps praxi je zásadní princip minimálních oprávnění: agent nemá mít přístup napříč repozitáři, pokud to není nezbytné, protože široký token z něj dělá ideální cíl.
- Uživatelský vstup z issue, pull requestů nebo komentářů se nesmí brát jako důvěryhodná instrukce pro model; je potřeba ho oddělit, filtrovat nebo sanitizovat před předáním agentovi.
- Riziko není jen v „chytrosti“ modelu, ale v tom, k jakému kontextu se dostane a co smí zveřejnit; organizace by proto měly omezit veřejné výstupy agentů a počítat s prompt injection jako se systémovou třídou zranitelností.
Postgres 19 přináší online zmenšování tabulek a rozumnější výchozí chování
Postgres 19 ve verzi beta staví do popředí hlavně novou funkci REPACK, která umí přepsat nafouknutou tabulku a vrátit místo na disku i bez dlouhého blokování provozu. Vedle toho se ve výchozím stavu vypíná JIT, protože u běžných OLTP dotazů často spíš přidával režii než výkon. Zlepšil se také plánovač dotazů, který nově umí v některých případech agregovat data ještě před JOINem a výrazně tím snížit počet zpracovávaných řádků. Finální vydání se čeká na podzim 2026.
- REPACK (CONCURRENTLY) řeší dlouholetý problém s bloatem přímo v jádře Postgresu: čtení i zápis běží dál a exkluzivní zámek se drží jen při závěrečné výměně souborů.
- JIT je nově vypnutý, což je praktické hlavně pro backendy s krátkými transakčními dotazy, kde čas kompilace často převážil nad samotným vykonáním SQL.
-
Optimalizátor dotazů je chytřejší: eager aggregation umí zmenšit mezivýsledky před JOINem,
NOT INse bezNULLmůže převést na rychlejší anti-join a přibyl ipg_plan_advicepro připnutí ověřeného plánu.
Node.js spustil náhled nové API dokumentace s vestavěným vyhledáváním
Node.js zveřejnil beta verzi přepracované API dokumentace na adrese beta.docs.nodejs.org a chce ji otestovat v reálném používání před ostrým nasazením. Samotný obsah dokumentace zůstává stejný, změnila se ale struktura, navigace a čitelnost. Novinka poprvé přidává vestavěné vyhledávání a sjednocuje vzhled s webem nodejs.org. Nová dokumentace navíc funguje i bez JavaScriptu a offline.
- Pro vývojáře je nejpraktičtější vestavěné hledání napříč API, rychlý přístup ke stránkám přes klávesovou zkratku a trvale viditelný přehled modulů i obsahu aktuální stránky.
- Dokumentace běží na novém nástroji doc-kit, který nahrazuje původní zastaralý generátor a může být zajímavý i pro další projekty, které chtějí generovat technickou dokumentaci z Markdownu.
- Node.js zároveň přidal soubor llms.txt, který dává nástrojům s AI čistý a strukturovaný vstup do referenční dokumentace, což může usnadnit integraci do interních asistentů a vývojářských workflow.
Jak fungují zálohy v Postgresu a proč je pro provoz klíčové průběžné archivování
Článek rozebírá tři hlavní způsoby zálohování Postgresu: logické zálohy přes pg_dump, kopii souborového systému a průběžné archivování pomocí WAL. Pro menší databáze je pg_dump jednoduchý a užitečný, ale u velkých a vytížených clusterů může dlouhý běh zvyšovat zátěž a v krajním případě přispět k problémům s transaction wraparound. Nejpraktičtější variantou pro produkci je průběžné archivování, které kombinuje base backup a WAL, funguje bez odstávky a umožňuje obnovu do konkrétního času. Právě tento přístup drží rozumný kompromis mezi rychlostí obnovy, bezpečností dat a dopadem na běžný provoz.
-
pg_dumpvytváří konzistentní logický snapshot a hodí se hlavně pro migrace, ale neumožňuje point-in-time recovery a u databází v řádu desítek TB výrazně zatěžuje CPU i diskové I/O. - Samotná kopie souborového systému je rychlá na zálohu i obnovu, jenže bez snapshotů na úrovni storage vyžaduje odstávku; pro online provoz je proto nutné ji doplnit o archivaci WAL.
- Průběžné archivování využívá WAL a
full_page_writesk opravě „rozmazaných“ dat během online base backupu, takže dovoluje obnovu do konkrétního okamžiku a zároveň se dá provozovat s menším dopadem na primární uzel.
Zalando přesunulo load balancing do aplikace a zvládlo milion požadavků za sekundu levněji i stabilněji
Zalando popsalo, jak pro interní provoz s vysokým fan-outem nasadilo client-side load balancer běžící přímo v procesu aplikace místo průchodu přes sdílený edge balancer. Cílem bylo snížit latenci, zlepšit předvídatelnost odezvy a přesněji odlišit problémy infrastruktury od chyb vlastní služby. Řešení zachovalo stejné hashování i routování jako původní Skipper, takže migrace nevedla k rozbití cache. Výsledkem byly nižší náklady, menší infrastruktura a lepší observabilita při špičkové zátěži kolem 1 milionu požadavků za sekundu.
- Klíčové bylo konzistentní hashování se stejným algoritmem a stejným počtem virtuálních uzlů jako ve Skipperu, takže oba přístupy směrovaly stejné klíče na stejné pody a minimalizovaly rozpad cache během rolloutu.
- Pro backend praxi je zajímavý způsob nasazení: watch-based Kubernetes informer místo pollingu, postupné přepínání od 1 % do 100 % přes feature toggles a fade-in nových podů během 30 sekund, aby se omezily latenční špičky při škálování.
- Dopad byl měřitelný: flotila Skipperu klesla z více než 50 podů na 8, denní náklady na deployment spadly z 450 na 110 dolarů a detailnější logování odhalilo krátké zamrzání jednotlivých uzlů, kterému se balancer umí sám vyhnout.
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.