Describe your BFF. Orchestrate every service in parallel.

When your product page needs data from six services, calling them sequentially adds their latencies together — 80ms + 95ms + 110ms + 80ms + 70ms + 90ms = 525ms. Apitide fans out to all independent services simultaneously. The response arrives in 110ms — the time of the slowest single call — not 525ms.

Apitide's dependency engine understands which calls can run in parallel and which must be sequential. Call B that needs call A's result runs after A. Everything else runs concurrently. You define the workflow steps; Apitide maximises parallelism automatically.

Partial failure handling is configurable per step: required steps fail the entire response, optional steps degrade gracefully with a default value, cacheable steps fall back to their last cached result. The policy lives in the workflow, not duplicated across every client.

Without validation at the orchestration boundary, malformed requests propagate into your backend services before you know they are invalid. A missing required field silently produces an incorrect database record. An integer where a string was expected causes a runtime panic three service hops downstream.

Apitide validates every inbound request against a JSON Schema definition before the workflow executes. If validation fails, the workflow stops immediately and returns a configurable HTTP error response — the error message, status code, and response body are all configurable per validation rule.

Validation also runs on upstream responses. When a service returns a response that doesn't match the expected schema — because it changed its API contract without notice — Apitide surfaces this as an explicit schema error rather than propagating corrupt data into your composed response. You learn about upstream API changes immediately, not when a user reports a broken page.

Some workflow steps don't need to complete before the response returns. Sending an event to your data warehouse, logging a user action to an analytics platform, or triggering a notification are all operations where the user doesn't wait for confirmation — and shouldn't.

Fire-and-forget steps execute asynchronously in the background. The workflow proceeds to the response step immediately, and the fire-and-forget step runs in parallel without blocking. Your response time reflects only the synchronous work; the background work happens independently.

This pattern eliminates a common performance antipattern: sequential calls to non-critical services that add latency to every user interaction. With fire-and-forget, data warehouse events, audit logs, and notification triggers add exactly 0ms to your user-facing response time.