# The Claim That Picks Its Own Lane > Three entry points. Different workflows. All must route correctly. Canonical URL: Domain: Pipeline Design · Difficulty: medium · Seniority: L5 ## Problem We process insurance claims submitted through multiple channels: agent portals, direct customer APIs, and bulk file uploads from partner brokers. Each claim goes through a series of processing steps - validation, fraud screening, adjuster assignment, and payment authorization - some automated and some manual. Design an event-driven pipeline that orchestrates this multi-step claims workflow. ## Worked solution and explanation ### Why this problem exists in real interviews An insurance claim workflow has to look the same regardless of which channel created it, has to pause for human steps that take days, and has to surface the regulatory clock before it breaches. The trap is per-channel pipelines that diverge or treating adjuster review as a pause that the system forgets is happening. The default reach is per-channel handlers that each implement validation, fraud screening, assignment, and payment. The portal pipeline ships a fix; the API pipeline doesn't get it for two weeks; broker bulk uploads run a different path entirely. Adjuster review is a synchronous wait that times out the workflow on long claims. Regulatory windows are tracked manually; some breach before anybody notices. > **Trick to Solving** > > One canonical claim event off any channel, durable workflow that survives long pauses, regulatory-clock alerting before breach. > > 1. All channels publish a canonical claim event onto one bus; downstream processing reads one shape regardless of the channel. > 2. An orchestrator owns the workflow with durable state; an adjuster-review step pauses the workflow and resumes on the adjuster's decision event. > 3. Regulatory windows live as timers per claim; the orchestrator alerts before each window's breach with the claim id and the time remaining. --- ### Walk the requirements #### Step 1: Canonical claim events off any channel; downstream processing is the same Each channel publishes a canonical claim event onto the bus; downstream processing reads one shape and the same workflow runs regardless of channel. A bug fix in the workflow lands once for everyone. A 'per-channel pipeline' design is the version where the portal pipeline ships a fix and the API pipeline drifts; canonical-up-front is what keeps them aligned. #### Step 2: Workflow pauses for adjuster review and resumes on decision The orchestrator runs the multi-step workflow with durable state. When a claim enters adjuster review, the workflow pauses; the orchestrator holds the state and waits for the adjuster's decision event. The decision arrives minutes later or days later; the workflow resumes from where it paused. A synchronous wait would time out long claims; durable pause-and-resume is what makes the human step part of the architecture. #### Step 3: Regulatory-window timers fire before breach Each claim has a regulatory acknowledgment window and a decision window. The orchestrator runs a per-claim timer that fires an alert before the window's breach with the claim id and the time remaining. On-call sees claims approaching breach and acts. Tracking the windows in a spreadsheet is the version that misses breaches; per-claim timers in the orchestrator catch them before the regulator does. --- ### The shape that fits > **What this design gives up** > > Canonical events require all channels to publish through the same contract; durable workflow state grows with concurrent in-flight claims; regulatory timers add per-claim state the orchestrator carries. Implementation cost is the price; the win is consistent processing across channels, long human pauses without timeouts, and regulatory windows surfaced before they breach. > **What reviewers check** > > A reviewer looks at the canvas for these properties: > - An event bus carries canonical claim events from all three channels. > - An orchestration layer runs the multi-step workflow with durable state across human pauses. > - Regulatory-window timers per claim alert before breach. > **The mistake that ships** > > What gets shipped runs per-channel pipelines and tracks regulatory windows in a spreadsheet. The portal's bug fix doesn't make it to the API pipeline for two weeks. Adjuster review times out long claims because the workflow doesn't durable-pause. Some claims breach the regulatory window because the spreadsheet missed them. The eventual rebuild adds canonical events, durable workflow state, and per-claim regulatory timers. --- ## Common follow-up questions - An adjuster takes a week to decide on a claim. What in this design lets the workflow stay paused without timing out? _(Tests whether the candidate sees the orchestrator's durable state holding the workflow's pause; the next step waits for the adjuster's decision event regardless of how long it takes. The state survives orchestrator restarts. A workflow-engine timeout is the failure mode; durable state is the contract.)_ - A new state regulator changes the decision window from one number to another. What changes in the design, and where? _(Tests whether the candidate sees the regulatory timer as configuration: a new threshold per state updates the timer's window, and the orchestrator picks it up on the next claim. The workflow steps don't change; the timer does.)_ ## Related - [All practice problems](https://datadriven.io/problems) - [Mock interview mode](https://datadriven.io/interview/the_claim_that_picks_its_own_lane) - [System Design Interview Questions](https://datadriven.io/data-engineering-system-design) - [Data Engineering Interview Prep Guide](https://datadriven.io/data-engineer-interview-prep) - [Daily Challenge](https://datadriven.io/daily) --- Source: DataDriven (https://datadriven.io). 100% free data engineering interview prep. Live code execution against Postgres 16, Python 3.11, and Spark sandboxes. No paywall, no premium tier, no signup gate.