Explanation¶
Why the subsystems here are built the way they are: the problem each one solves, the alternatives that were weighed, and the properties the chosen design buys.
These pages give the shape of a design. A single choice, with its drivers and its consequences, is recorded instead in Decisions.
Documents¶
| Document | Summary |
|---|---|
| Kudos accounting, projection, and concurrency | Why kudos movements are recorded as typed events, how the projector materializes them, and how spends stay safe while balances lag. |
| Request feasibility and queue pressure | Practical guidance for using request progress, worker compatibility, capacity counts, queue estimates, and stall warnings in API clients. |