A customer submits an order with an email field containing "not-an-email". Your system accepts it, processes it, creates shipping labels, sends confirmation. Then the email bounces. Now you have an order with no way to contact the customer.
Three days later, an integration sends a product price as "fifteen dollars" instead of 15.00. Your inventory system crashes. It takes four hours to find because the error shows up three steps downstream, nowhere near the actual problem.
Your team spends 40% of debugging time tracing bad data back to its origin. Every bug report starts with "where did this come from?"
Validation catches problems at the gate. Verification confirms they stay fixed.
TRANSFORMATION COMPONENT - Every hour spent on validation saves ten hours debugging downstream failures.
Validation checks that incoming data matches expected formats and constraints: Is this email actually an email? Is this number within valid range? Does this required field exist? Verification goes further - confirming the data is not just formatted correctly but actually true: Does this customer ID exist in our database? Is this address deliverable?
The key insight is separation of concerns. Input validation happens immediately - before the data touches your business logic. Schema validation ensures structure. Business rule validation ensures meaning. Each layer catches different classes of errors. Catch format errors first, then constraint violations, then business logic failures.
Good validation returns specific, actionable errors. 'Invalid input' tells you nothing. 'Email must contain @ symbol' tells you exactly what to fix.
Validation is a gate, not a filter. Data either passes completely or fails with clear reasons. Never partially accept bad data and try to fix it later.
Receive → Check Format → Check Constraints → Check Business Rules → Accept or Reject. Each layer runs only if the previous passes. Fail fast, fail clearly.
Select different scenarios to see how each validation layer catches specific types of problems.
{
"customer_id": "CUST-2847",
"email": "jane@acme.com",
"quantity": "50",
"product_sku": "SKU-9921",
"ship_date": "2025-01-15"
}Order Accepted: All validation layers passed. Order is safe to process.
Does it have the right shape?
Check that required fields exist, types match expectations, and structure is correct. Is price a number? Does address have city and zip? JSON Schema, Zod, Yup - pick your tool. This catches "you sent me garbage" errors.
Is it within allowed bounds?
Check that values meet constraints: quantity > 0, date is in the future, email matches pattern, string length within limit. These are rules that apply regardless of business context - universal truths about the data.
Does it make sense in context?
Check that data satisfies business requirements: customer exists and is active, product is in stock, user has permission for this action. These rules require database lookups and domain knowledge.
A partner system submits an order via API. Instead of blindly accepting and discovering problems during fulfillment, validation catches issues immediately. missing fields, invalid quantities, unknown SKUs, inactive customers. returning clear errors or confirming the order is safe to process.
Hover over any component to see what it does and why it's neededTap any component to see what it does and why it's needed
Animated lines show direct connections · Hover for detailsTap for details · Click to learn more
Your beautiful React form validates everything. But someone uses curl to hit your API directly. Your server accepts 'quantity: -5' because you trusted the client. Now your inventory system shows negative stock.
Instead: Always validate server-side. Client validation is UX, not security. Treat all incoming data as untrusted.
Your API returns "Validation failed" for 15 different errors. Users submit support tickets. Developers add console.log statements. Nobody knows what actually went wrong without reading code.
Instead: Return specific field-level errors: { "errors": [{ "field": "email", "message": "Must be valid email format" }] }
You check if the customer exists before checking if the email is valid. Your database gets hit with SELECT queries for malformed emails. Under load, you're wasting resources on obviously bad requests.
Instead: Validate cheap things first: format → constraints → database lookups. Fail fast before expensive operations.
You've learned how to catch bad data at the gate. The natural next step is enrichment - adding information to valid data from external sources to make it more complete and useful.