Limits as tools
Why it matters The default design assumes plenty: a server that remembers, data you can read twice, a network that is always there, memory to spare. Take one of those away and the obvious design stops working, and what replaces it is often simpler to run and harder to break.
Some limits are imposed: a phone that goes offline in a tunnel, a router with a few kilobytes of memory, a stream that cannot be rewound. Others are chosen on purpose, because designing as if the limit were there removes a whole class of failure.
Stateless server: a server that keeps nothing between requests. Every request carries what it needs. Any server can answer it, and a restart loses nothing.
Four limits, four designs
- No server state leads to signed, self-contained tokens: the client holds the data, a signature proves it was not changed.
- One pass only leads to running summaries that update with each item.
- Offline first leads to logs of operations that can be merged, instead of copies that overwrite each other.
- Fixed memory leads to approximate answers with a stated error bound.
The skill is to ask, early: "what if we could not do the thing the default design depends on?" Sometimes the answer is a better design even when the limit is not real.
Recap A limit removes the default and forces a choice. Many of the best-known designs (signed tokens, streaming, mergeable data, sketches) came from a limit.
Spotted a problem in this lesson? Report it · Ask about this lesson
This exercise opens soon
Finish the lesson before it and this one unlocks. The whole course is free, no account needed, and you can read this lesson right now.
This browser is blocking cookies for learn.floati.life, so lessons you finished here cannot open in order. Allow cookies for this site and reload.