Exactly-once claims and the reality
Why exactly-once is an application-level property, not a network guarantee.
Averho knowledge
Every concept in the curriculum, grouped by the path it belongs to. Read them in order, or start wherever the question you have today lives.
5of 50 available now
Build workflows that survive retries, partial failures, and reordered messages.
How to make repeated operations safe in the presence of retries.
Bound waiting time and recover from transient failures without amplifying load.
Decouple producers from consumers to smooth load and isolate failures.
Publish events reliably by writing them in the same transaction as state.
Where synchronous calls help and where they create fragile coupling.
Why exactly-once is an application-level property, not a network guarantee.
Coordinate multi-step business processes without holding locks end-to-end.
Isolate unprocessable messages and give humans a path to resolve them.
Let a system signal overload instead of collapsing under it.
Instrument workflows so retries, duplicates, and stalls are visible.
Make systems handle more load without spending more than the load is worth.
What caching actually buys and why invalidation is the hard half.
Precompute query-shaped data instead of deriving it on every request.
Design indexes from the queries you actually run, not from the schema.
Why a database falls over long before the application does.
When adding machines beats adding capacity to one machine.
Split data across nodes and live with the queries that no longer work.
Protect shared capacity by deciding whose requests get refused.
Measure latency honestly with percentiles before optimizing anything.
How threads, event loops, and async runtimes spend a machine differently.
Find the breaking point deliberately instead of discovering it in production.
Design the contracts and edges where independent systems meet and evolve.
Find the seams where a system naturally splits, before distributing anything.
Pick an interaction style from the coupling it creates, not from fashion.
Publish facts instead of commands, and accept the consequences.
Depend on a system you do not control without inheriting its failures.
Evolve a contract without breaking the consumers already using it.
Keep a foreign model from leaking into the core of your system.
Get boundaries and independence without paying for the network.
Extract services incrementally and earn the cost of distribution.
Why a shared database is the coupling that outlives every refactor.
How organisation shape constrains architecture, and how to use that.
Run systems in production: observe, deploy, recover, and secure with intent.
The three signals and the questions each one can actually answer.
Page a human only when a human can and must do something.
Separate deploying code from releasing behaviour.
Keep configuration explicit, versioned, and separate from code.
Store, rotate, and scope credentials without leaking them.
Ship changes with a rollback path baked into the mechanism.
Coordinate during outages and learn from them blamelessly afterward.
Probe failure modes deliberately before they surprise you.
A backup you have never restored is a hypothesis, not a plan.
The handful of failures that account for most real breaches.
Model, store, and evolve data so it stays correct as the system grows.
Model the domain's real entities, relationships, and invariants.
Trade write simplicity against read speed on purpose.
What each isolation level prevents and the anomalies it still permits.
Store state as an append-only log of the decisions that occurred.
Move data between systems from the log instead of from dual writes.
Decide what to keep, for how long, and where it lives afterward.
Change schemas without downtime, data loss, or a big-bang cutover.
Model the read and write sides separately when their needs diverge.
Strong, eventual, and causal consistency, and what each one costs.
Enforce invariants at the boundary so bad data never lands.