One path to data

Every read and write through a single observable pipeline. The value isn't purity — it's that you only have one place to look when something is slow, wrong, or leaking.

Systems rarely start with side doors. They accumulate them: a reporting job that reads the database directly, an admin script with its own connection, a webhook that writes a table nobody else touches. Each is reasonable alone. Together they mean no single place describes what happens to your data.

Routing everything through one resolver path is mostly a debugging decision. When every read and write crosses the same boundary, that boundary is where you add tracing, per-request encryption, audit logging and rate limiting — once, rather than per caller.

What it looks like in practice

• A single compute entry point rather than one function per field — one place to log, trace and reason about.
• Schema as the contract. If it isn't expressible in the schema, it isn't reachable.
• Background jobs call the same path as the UI. No privileged shortcut that skips the checks.

The objection is performance: a single path sounds like a single bottleneck. In a serverless setup it isn't — the path is a code route, not a server, and it scales per request. What you actually pay is discipline, because the shortcut is always available and always faster to write.

The point of one path isn't elegance. It's that audit, tracing and encryption become properties of the system rather than habits of the team.