Data Validation

A hospital system accepts patient ages as free-text input. One day, someone enters "two hundred and fifty" as an age. The system stores it. A downstream report calculates the average patient age and returns 87 years because a single junk value skewed the entire dataset. A doctor makes treatment decisions based on demographics that are now wrong.

This is the oldest rule in computing: garbage in, garbage out. If you allow bad data to enter your system, every calculation, report, and decision downstream is potentially wrong. And the further bad data travels, the harder it is to find and fix.

Stripe's API rejects about 12 percent of incoming requests at the validation layer before they ever touch business logic. That is 12 percent of potentially dangerous or malformed data stopped at the front door. Without that gate, their payment processing would be unreliable.

Data validation is the practice of checking every piece of data against a set of rules before it enters your system. Is this field a number? Is it within a reasonable range? Does this email address have an @ symbol? Is this date in the past, not the future? Validation catches problems at the door, before they contaminate your data stores.

Validation is not a single checkpoint. It happens at four layers, and each one catches different problems:

The layers work in series. Client-side validation gives instant UX feedback but can be bypassed by anyone with curl or Postman. API schema validation is the real gatekeeper, about 95 percent of malformed input dies here. Business logic applies rules that need database state ("does this email already exist?"). Database constraints are the final safety net that catches race conditions and bugs.

Never trust a single layer. Client-side can be bypassed. Schemas cannot check business rules. Business logic has race conditions. Database constraints give cryptic error messages. Together, they form a defense-in-depth strategy where each layer compensates for the weaknesses of the others.