Form Builder Low-Level Design: Dynamic Schema, Conditional Logic, and Submission Pipeline

What Is a Form Builder?

A form builder lets non-technical users design data collection forms through a visual interface, while the underlying system manages the schema definition, enforces conditional field logic at runtime, validates and processes submissions, and delivers captured data to downstream systems via webhooks. It is a common product requirement across SaaS platforms, internal tools, and customer-facing applications.

Requirements

Functional Requirements

Allow users to create forms with typed fields: text, number, date, dropdown, checkbox, file upload.
Support conditional logic: show/hide or require fields based on the values of other fields.
Validate submissions against the form schema server-side before accepting them.
Store submissions and make them queryable by form owners.
Deliver submissions to registered webhook endpoints with retry on failure.

Non-Functional Requirements

Form rendering schema must be fetchable in under 200 ms globally (CDN-cacheable).
Submission validation and storage must complete within 500 ms for 99% of requests.
Webhook delivery must achieve at-least-once semantics.
Support up to 10,000 submissions per minute per form during peak campaigns.

Data Model

Form

form_id (UUID)
owner_id (foreign key to users table)
title, description
schema (JSONB: ordered array of field definitions)
logic_rules (JSONB: array of conditional rule objects)
published (boolean), version (integer)

Field Schema (within the JSONB array)

field_id (UUID), label, type, required
options (for dropdowns/checkboxes: array of label/value pairs)
validation (JSONB: min, max, pattern, max_length)

Submission

submission_id (UUID)
form_id, form_version (snapshot of version at submission time)
data (JSONB: field_id to value map)
metadata (JSONB: submitter IP, user agent, referrer)
submitted_at, webhook_status (ENUM: pending, delivered, failed)

Core Algorithms

Conditional Logic Evaluation

Logic rules are stored as an array of condition-action pairs. Each rule has the structure: when field X satisfies condition Y, then apply action Z to field W. Supported conditions: equals, not equals, contains, greater than, less than. Supported actions: show, hide, require, unrequire.

At render time, the client evaluates rules in order against the current field values. On the server, the same rule set is re-evaluated during submission validation to determine which fields are active. Only active fields are validated for required constraints. This prevents server-side bypass by clients that omit hidden fields.

Submission Validation Pipeline

Validation runs as a sequential pipeline of steps:

Schema existence check: the form_id exists and is published.
Field completeness: all required active fields are present in the submission data.
Type coercion and format check: values match declared types (e.g. date fields parse as ISO 8601).
Constraint validation: numeric ranges, string patterns, and max lengths are enforced.
File reference validation: file upload fields reference a pre-uploaded object key owned by this form session.

If any step fails, the pipeline returns a structured error response listing all field-level violations rather than stopping at the first failure.

Scalability

Published form schemas are immutable once a submission is received against them. This allows aggressive caching: the schema JSON is stored in object storage and served via CDN with a long cache TTL. When a form owner publishes an update, a new version is created and the CDN cache for that form is purged. Submissions always record the form_version they were validated against, ensuring historical correctness.

Submission writes go directly to a partitioned PostgreSQL table (partitioned by form_id hash) for low-latency writes. A separate read replica handles owner queries over submission data. For very high-volume forms, an async write path buffers submissions in a queue and writes them in batches, trading slightly increased submission latency for higher throughput.

API Design

POST /forms — create a form with schema and logic rules.
PATCH /forms/{form_id} — update schema or rules; increments version and optionally republishes.
GET /forms/{form_id}/schema — return the published schema for client rendering (CDN-cacheable).
POST /forms/{form_id}/submissions — submit a completed form; runs validation pipeline and stores result.
GET /forms/{form_id}/submissions — list submissions with filtering by date range and pagination.
POST /forms/{form_id}/webhooks — register a webhook endpoint for new submissions.

Webhook Delivery

After a submission is persisted, a webhook delivery job is enqueued. The job POSTs the submission payload to each registered endpoint with an HMAC-SHA256 signature header for verification. On non-2xx response or network timeout, the job is retried with exponential backoff (1s, 5s, 30s, 5m, 30m). After 5 failed attempts, the webhook is marked as failed and the form owner is notified. A dead-letter endpoint stores failed payloads for manual inspection.

Observability

Track submission rate per form, validation failure rate and breakdown by failure type, webhook delivery latency and failure rate, and schema cache hit rate. Alert on submission error rate exceeding 2% or webhook failure rate exceeding 10% for any form over a 5-minute window.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How is a form defined using JSON schema in a form builder system?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Each form is stored as a JSON document describing an ordered array of field objects, each with properties for field type (text, select, checkbox, file), label, placeholder, validation rules (required, min/max length, regex), and an optional visibility condition expression. The renderer reads this schema and constructs the UI dynamically, making form changes a data operation rather than a code deployment.”
}
},
{
“@type”: “Question”,
“name”: “How does conditional field logic evaluation work in a form builder?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Each field's schema can carry a `showIf` expression referencing other field values, e.g., `{“field”:”country”,”op”:”eq”,”value”:”US”}`. The client-side engine evaluates these expressions reactively on every field change event, toggling field visibility and resetting hidden field values. Complex conditions are composed with AND/OR operators represented as nested expression trees.”
}
},
{
“@type”: “Question”,
“name”: “What does the submission validation pipeline do before persisting form data?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “The pipeline re-evaluates all field-level validation rules server-side (never trusting client validation alone), checks cross-field constraints (e.g., end date must be after start date), runs any custom async validators (e.g., address verification API), and sanitizes input against XSS and injection patterns. Only after all stages pass does the pipeline write the submission to the store.”
}
},
{
“@type”: “Question”,
“name”: “How does a form builder deliver submission data via webhooks?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “After a validated submission is persisted, the service looks up any configured webhook endpoints for that form, serializes the submission as a JSON payload, and enqueues a delivery job. The job POSTs to the endpoint with an HMAC-SHA256 signature header so the receiver can verify authenticity. Failed deliveries are retried with exponential backoff up to a configurable max attempts before the event is dead-lettered.”
}
}
]
}