Eventual consistency
Related service Website & online shop
DEFINITION
Eventual consistency means that if no new writes hit a distributed system, readers will, given enough time, all see the same value, but enough time is not the same as immediately. The CAP theorem says under a partition you must pick between strict consistency and availability, and many modern data layers (S3, DynamoDB read replicas, Redis replicas, read models behind an event bus) optimise for the latter. Practical implications for a dashboard: the user clicks save, the POST returns 200, but the next GET still shows the old value because the read replica has not replicated yet. What to do: 1) read-your-writes pattern (the client passes a version or ETag for the just-written resource, and optimistically updates local state). 2) Soft-loading state plus skeleton plus retry. 3) A single source of truth (TanStack Query, SWR) that handles stale-while-revalidate. Never build UI that assumes a backend response is instantly visible globally.
- SSR (Server-Side Rendering)→
HTML rendered by the server per-request, fresh for every user. Ideal for dynamic content (dashboards), but slower than SSG.
- SSG (Static Site Generation)→
Pages are produced at build time as HTML and served from a CDN. Near-zero TTFB. DField's own site runs this way across 111+ pages.
- ISR (Incremental Static Regeneration)→
SSG + timed regeneration: the HTML is static but regenerates on a schedule. Ideal for blog content · freshness with CDN speed.
- Edge rendering→
Code runs at the CDN edge closest to the user (Cloudflare Workers, Vercel Edge). Dynamic responses with ~10–50 ms TTFB.
- RSC (React Server Components)→
React components that run exclusively on the server and never ship to the browser. Result: less client-side JS and faster hydration.
- LCP (Largest Contentful Paint)→
Time until the largest visible element paints. Google Core Web Vitals passes under 2.5s · we usually land marketing pages under 1s.