adapter
- Topologie
- Four route pools behind the ext_proc routing service
- Cache Next
- Shared Dragonfly cache handler
- Scalare
- Independent HPA per pool
Next.js pe Kubernetes
O singură aplicație intenționat dificilă, două arhitecturi de deployment. Fiecare probă este construită ca să facă o diferență de infrastructură vizibilă, nu doar plauzibilă.
Acoperire
Server Components, HTML streaming and request-time rendering inside the web pool.
Prefetching, persistent layouts, parallel and intercepting routes, instant transitions.
PPR, `use cache` profiles, remote cache coherence and tag invalidation across replicas.
Prisma/PostgreSQL, Redis, Server Actions, forms and Draft Mode.
App Router `route.ts` methods, bodies, uploads and lifecycle work.
SSE, byte-observable streams, cancellation and signed webhook delivery.
next/image optimisation, generated metadata, icons, OG images and static files.
proxy.ts, rewrites, redirects, header matching, auth and error boundaries.
getStaticProps/getServerSideProps, Pages API and the Edge runtime handler.
Health probes, Prometheus metrics, pool-isolated load and runtime identity.
Începe aici
One mutation invalidates every replica; the cache nonce is identical whichever pod answers.
Prefetching an unknown slug warms the shared cache without blocking the shell.
Every pod reaches the same database with a healthy connection pool.
Envoy and Cloudflare forward each reveal without coalescing the response.
The shared layout stays mounted and interactive while the payload arrives.
An action submitted to one replica stays decryptable and revalidates every other replica.