Validation & Trust

Three different validations that are routinely confused: is this well-formed, is this allowed by the business, and is this consistent with what the database already holds.

The Three Validations

Well-formed, permitted, and consistent are three different questions with three different enforcement points — and only the last one survives a race.

Q · When someone says "we validate that", which of three completely different checks do they mean?
Transport Validation

The only check that needs no state: is this payload the right shape, the right types, and small enough to look at?

Q · What can a schema at the edge actually guarantee, and what does it silently let through?
Business Validation

Rules that need loaded state and an actor — and the fact that every answer they give is already stale.

Q · Where do rules that need to look something up belong, and what is the guarantee they give you?
Database Constraints

The only check evaluated inside the write — which is why it is the only one that survives two requests arriving at the same instant.

Q · Why is "email must be unique" a database problem rather than an application one?
Parse, Do Not Validate

A check that returns a boolean throws away what it learned; a check that returns a typed value hands the knowledge to every line below it.

Q · Why does validation keep happening more than once, in more than one place, with slightly different rules?
Every Input Surface

Body, query, path, headers, cookies, files, webhooks, external responses — and the second-order case where your own database hands back something a request wrote.

Q · Which surfaces carry untrusted input, and what is the specific check each one needs?
Reporting Validation Failures

Three layers reject for three reasons, so one 400 with a sentence in it is the wrong answer to all three.

Q · What should a rejected request actually return, and how much can you safely say?