Idempotency key
Kapcsolódó szolgáltatás Weboldal és webshop
MEGHATÁROZÁS
Az idempotency key egy kliens által generált egyedi azonosító (általában UUID), amit a request header-ben küldünk (Idempotency-Key) minden olyan POST, PUT vagy DELETE hívásnál, ami állapotot változtat. A fizetési API-k (Stripe, Adyen, SimplePay, PayPal) ezt arra használják, hogy ha ugyanazzal a key-jel kétszer érkezik a kérés (mert a network szakadt, a kliens újrahívott, a load balancer retry-olt), akkor garantáltan csak egyszer hajtsák végre, és a második válasz az első cached eredménye legyen. Enélkül egy 30 másodperces timeout után retry-oló kliens kétszer terhel le 100 ezer forintot. A retry logika nem létezhet idempotency key nélkül a payment, az order placement, az email küldés és a webhook delivery rétegén. Saját API-nál is érdemes: tegyünk fel egy Postgres unique indexet a key-re, és vagy a hívás előtt vagy az esemény-soron oldjuk meg.
- SSR (Server-Side Rendering)→
A HTML-t a szerver rendereli kérésre, minden felhasználónak frissen. Dinamikus tartalomra (dashboard) ideális, de lassabb, mint az SSG.
- SSG (Static Site Generation)→
Az oldalak build-időben készülnek el HTML-ként, és egy CDN szolgálja ki őket. Szinte nulla TTFB. A DField saját oldala 111+ oldallal fut így.
- ISR (Incremental Static Regeneration)→
SSG + időzített regeneráció: a HTML statikus, de megadott intervallumban újragenerálódik. Blog-cikkekhez ideális · frissesség CDN-sebességgel.
- Edge rendering→
A kód a felhasználóhoz legközelebbi CDN-pontban fut (Cloudflare Workers, Vercel Edge). Dinamikus válasz ~10–50 ms TTFB-vel.
- RSC (React Server Components)→
React-komponensek, amik kizárólag szerveren futnak, és nem kerülnek át a böngészőbe. Eredménye kevesebb kliens-oldali JS és gyorsabb hydration.
- LCP (Largest Contentful Paint)→
A legnagyobb látható elem megjelenésének ideje. Google Core Web Vitals zöld küszöbe 2.5s alatt · mi jellemzően <1s alá lőjük a landing oldalakat.
Még nincs cikk, ami ezt a fogalmat használja.