Cache
InfrastructureA kept copy of something expensive to produce.
A stored result reused instead of being recomputed or refetched. The most effective performance tool available and the source of the most confusing bugs, because a copy can be out of date. Copies live in the browser, the CDN, and your server.
See also CDN, Invalidation, TTL
DNS
FrontendThe system turning names into addresses.
Translates a domain name into the numeric address of a machine. Results are cached in many places you do not control, which is why a DNS change can take hours to be seen everywhere.
See also Latency, TLS
Invalidation
InfrastructureTelling a cache its copy is now wrong.
Actively clearing cached copies when the underlying data changes. Always fresh, but you own the job of finding every place a copy might live. Content-based filenames avoid needing it at all.
See also Cache, TTL, CDN
REST
BackendAn API style organised around things.
Endpoints named after resources (/users, /orders) with HTTP verbs saying what to do to them. Highly cacheable and easy to inspect. A rich screen may need several calls.
See also GraphQL, RPC, Endpoint
Server state
FrontendData fetched from an API, held in the UI.
Not really your application’s state, but a cache of somebody else’s, which goes stale the moment anyone else changes it. Treating it as local state is what produces "I updated it but the list still shows the old value".
See also State, Cache
TTL
InfrastructureHow long a cached copy stays valid.
Time to live: the expiry on a cached item. Simple to reason about, at the price of accepting staleness up to that duration.
See also Cache, Invalidation