Systems
Grit is not one system. It is around thirty of them sharing a process: the thing that decides who you are, the thing that decides what you may touch, the thing that holds a queue, the thing that keeps a cache honest.
The rest of the documentation explains how to use each one. These pages explain how each one is built and why, in the order a system design question asks: the problem, the requirements, the numbers, the architecture, the data, the API, the types, the scaling, and what breaks first.
Every page describes what is actually built, at the version you are reading. Where a number is an estimate it says what it was estimated from, so you can change an assumption and redo the sum for your own traffic.
Identity
Who the caller is, and how they prove it.
Proving who the caller is, on every request, without asking them for a password more than once.
Turning a stateless token into something you can revoke, list by device, and expire two different ways.
A second factor that survives a leaked password, without locking out the user who loses their phone.
A credential that cannot be phished, cannot be reused across sites, and leaves nothing worth stealing in the database.
Access
What that caller is allowed to touch, and what stops them touching the rest.
Deciding what a known caller may do, in a way that fails closed and can be listed route by route.
Making "your invoices" mean yours, in the query rather than in the handler, so a forgotten check is not a breach.
One deployment serving many organisations, where a missing predicate is a data breach rather than a bug.
Keeping one caller from consuming the capacity of all of them, and making a password-guessing attack cost something.
Data
Where the application state lives, how it changes, and how it stays correct.
Serving a repeated answer without asking again, while keeping a cache failure a slowdown rather than an outage.
Two people editing the same record, and the second one finding out rather than silently winning.
Changing the shape of a live database, and being able to undo a run in a framework that has no migration files.
Returning a slice of a large table with a total, a sort, a filter and a search box, without the query getting slower as the table grows.
Making a column unreadable without the key, while the handler and the model carry on treating it as a string.
Delivery
Getting work out of the request path and getting results back to the client.
Getting slow work out of the request path, and having it survive a retry, a duplicate and a deploy.
Running something every night, exactly once, across however many replicas happen to be up.
Saving a row and telling the world about it as one atomic act, when the database and the message broker cannot share a transaction.
Pushing a change to the browsers that care about it, across replicas, with a fallback for the proxies that eat WebSockets.
Receiving a call from someone else’s system and believing it, and making one to theirs that survives their outage.
Getting a password reset into an inbox, through whichever provider is configured, without the request waiting for it.
Operations
Knowing what the system did, and being able to say so afterwards.
Being able to answer what happened, where the time went, and whether the thing is actually working, from outside the process.
Recording who did what, in a form that can be shown afterwards not to have been edited.
Accepting an upload, keeping it somewhere that survives a redeploy, and serving it back to the people allowed to see it.
Taking a spreadsheet somebody has and turning it into rows, and giving them a file back, without either one taking the application down.
Platform
The parts that generate, migrate and run everything above.
Turning one field list into a model, a service, a handler, routes, a schema, types, hooks and an admin page, and being able to take all of it back out.
One response envelope, one table of error codes, and the reason a client written against one endpoint works against all of them.
Turning a feature on for ten per cent of users without a deploy, and having the same user stay in the same group.
26 systems documented.