The Claim That Picks Its Own Lane
A medium Pipeline Design interview practice problem on DataDriven. Design the pipeline on the canvas: sources, transforms, storage and checks, then get feedback on it.
- Domain
- Pipeline Design
- Difficulty
- medium
- Seniority
- L5
- Asked in
- Travelers
Problem
Every insurance claim moves through validation, fraud screening, adjuster assignment, and payment authorization, where some steps are automated and the manual ones can hold a claim for a long time before it moves on. Design an event-driven pipeline that orchestrates this multi-step claims workflow.
Three entry points. Different workflows. All must route correctly.
Business requirements
- Claims arrive through agent portals, customer APIs, and broker bulk uploads; the downstream processing has to be the same regardless of how the claim came in.
Worked solution and explanation
This is a workflow with human-length pauses, dressed up as claim intake. Everyone draws three channels and an arrow. The trap is giving each channel its own validation and fraud code, or letting the adjuster step sit inside a synchronous call. Get that wrong and a fix ships to the portal lane while the API lane drifts for weeks, and any claim waiting on a person for days is a claim the system has quietly forgotten.
Build it in three moves
Step 1: Converge everything on event_bus
The portal, the customer API and the broker bulk uploads each publish onto one Kafka topic. Past that point nothing knows which door the claim came through. That single queue tier is what stops you maintaining three parallel implementations.
Step 2: Validate once, before any workflow step
claim_validation sits between the bus and the orchestrator, so a malformed bulk row and a malformed portal form fail the same check. Bad claims never become workflow state.
Step 3: Let the orchestrator own the claim's place
Fraud screening, assignment and payment authorization are steps in one workflow run by orchestrator. The adjuster review is a step that holds the claim and resumes when the decision arrives, whether that takes ten minutes or ten days. A person is a step in the graph, not a timeout waiting to happen.
- agent_portal (source, API)
- customer_api (source, API)
- broker_uploads (source)
- event_bus (queue, Kafka)
- claim_validation (quality gate)
- orchestrator (transform, Airflow)
- adjusters (consumer)
- claims_warehouse (storage, warehouse)
- agent_portal -> event_bus
- customer_api -> event_bus
- broker_uploads -> event_bus
- event_bus -> claim_validation
- claim_validation -> orchestrator
- orchestrator -> adjusters
- orchestrator -> claims_warehouse
- Per-channel pipelines
- Three copies of validation and fraud logic. A fix lands in one lane. Bulk uploads end up on a path nobody else reads.
- One bus, one workflow
- One
event_busand oneclaim_validationgate. A fix lands once for every channel, and the orchestrator sees one claim shape.
Common follow-up questions
- An adjuster takes a week to decide. What in this design keeps the claim from being lost or timed out? (Tests whether the candidate puts the long wait inside `orchestrator` rather than in a service call.)
- Broker uploads arrive as a file of 50,000 claims. How do they enter without becoming a special path? (Tests splitting a file into one event per claim on `event_bus`, so downstream stays identical.)