System Design: Insurance Platform

Requirements

Functional Requirements:

• Quote generation for multiple insurance products (auto, home, life, health) with instant pricing
• Policy lifecycle management: issuance, endorsements (mid-term changes), renewals, cancellations
• Automated underwriting with rules-based and ML risk assessment
• Claims intake, adjudication, and settlement processing
• Premium calculation engine supporting rating factors, discounts, surcharges, and regulatory rate filings
• Agent/broker portal for policy servicing and commission tracking

Non-Functional Requirements:

• Generate quotes in under 3 seconds for instant online binding
• Process 50,000 claims/day with automated adjudication for 60% of simple claims
• 99.9% availability for quote and bind flows
• Compliance with state-specific insurance regulations across 50 US states
• Audit trail for all policy changes and underwriting decisions

Scale Estimation

With 10M active policies across all product lines: auto (6M), home (3M), life (1M). Quote volume: 500K quotes/day (5.8 quotes/sec) with a 5% bind rate = 25K new policies/day. Claims: 50K claims/day = 0.58 claims/sec, with average 3 touchpoints per claim (intake, assessment, settlement) = 150K claim events/day. Policy changes (endorsements): 20K/day. Premium calculation requires evaluating 50-200 rating factors per quote depending on product line. Renewal processing: 10M policies ÷ 12 months = 833K renewals/month, concentrated in monthly batch runs. Commission calculations: 25K daily new policies × 10% average commission = $2.5M/day in commission disbursements across 100K agents.

High-Level Architecture

The insurance platform follows a product-agnostic architecture where a configurable Product Engine defines the behavior for each insurance product (auto, home, life) through configuration rather than code. This enables launching new products without engineering changes. The system is organized into core domains: Quoting & Rating, Policy Administration, Underwriting, Claims, and Billing.

The quoting flow: Customer enters risk information (vehicle details, driving history for auto; property details, claims history for home) → the Rating Engine evaluates the risk using product-specific rating algorithms (multiplicative rating for auto, additive for home) applying base rates, territory factors, driver factors, discount multipliers → the Underwriting Engine validates eligibility (no excluded risks, meets minimum standards) and determines if additional information is needed → a bindable quote is presented with premium, coverage details, and terms.

Policy administration uses an event-sourced model where the policy is a sequence of immutable events: ISSUED, ENDORSED, RENEWED, CANCELLED. The current policy state is a projection of all events. This design naturally handles complex scenarios like backdated endorsements (inserting an event in the past and re-projecting forward to recalculate premiums from that date). The Claims system operates semi-independently, linking to policies for coverage verification but maintaining its own lifecycle.

Core Components

Rating & Premium Engine

The Rating Engine is the actuarial pricing brain. It implements product-specific rating algorithms configured via rating tables (maintained by actuaries through an admin UI). For auto insurance, the multiplicative algorithm: base_rate × territory_factor × age_factor × vehicle_factor × driving_record_factor × credit_factor × discount_multiplier = final_premium. Rating tables map input values to factors (e.g., ZIP code 10001 → territory factor 1.85, driver age 25 → age factor 1.20). The engine supports effective dating — rating tables have effective_from and effective_to dates, ensuring quotes use the rates in effect at the policy effective date. State-specific regulatory constraints are enforced: some states prohibit credit-based pricing (California), others cap territorial variation. The engine is implemented as a rules interpreter that evaluates a JSON-defined rating plan, enabling actuaries to deploy rate changes without code releases.

Claims Adjudication Engine

The Claims Engine processes claims through: intake (FNOL — First Notice of Loss, capturing loss details, photos, police reports), assessment (coverage verification, damage estimation, liability determination), and settlement (payment calculation, deductible application, disbursement). Automated adjudication handles simple claims (e.g., windshield replacement: verify coverage, confirm deductible, approve up to coverage limit) without human intervention using a rules engine. Complex claims (bodily injury, disputed liability, high-value losses) are routed to human adjusters with AI-assisted assessment: computer vision models estimate vehicle damage from photos (trained on 1M+ historical claim photos), and NLP models extract key facts from police reports and witness statements. Subrogation detection (identifying whether another party is liable) uses ML models analyzing loss circumstances.

Policy Administration System

The Policy Admin System manages the full policy lifecycle using event sourcing. Each policy is represented as a stream of events stored in an append-only PostgreSQL table. Key event types: PolicyIssued (initial terms, coverages, premium), EndorsementApplied (changed fields, effective date, premium adjustment), RenewalOffer (new term, updated premium, coverage changes), Cancellation (reason, effective date, return premium calculation). The current policy state is projected by replaying all events in sequence. Mid-term endorsements trigger premium re-rating from the endorsement effective date: if a policyholder adds a vehicle 3 months into a 12-month policy, the Rating Engine calculates the pro-rata premium for the remaining 9 months. The system supports policy versioning — each endorsement creates a new policy version, and historical versions are accessible for claims that occurred under prior coverage terms.

Database Design

The primary store is PostgreSQL with event-sourced tables. policy_events (event_id, policy_id, event_type, event_data JSONB, effective_date, created_by, created_at) stores the immutable event stream. A materialized policy_current_state table is maintained by event handlers: policy_id, product_type, policyholder_id, status ACTIVE/CANCELLED/EXPIRED, effective_date, expiration_date, current_premium, coverages JSONB, endorsement_count, last_event_id. This materialized view is rebuilt on-demand if it diverges from the event stream.

Claims use a separate schema: claims (claim_id, policy_id, policy_version, loss_date, reported_date, status OPEN/UNDER_REVIEW/SETTLED/CLOSED/DENIED, loss_type, loss_description, estimated_amount, settled_amount, adjuster_id), claim_documents (document_id, claim_id, type PHOTO/POLICE_REPORT/ESTIMATE/RECEIPT, s3_key, uploaded_at). Rating tables are version-controlled: rating_tables (table_id, product_id, table_name, effective_from, effective_to, data JSONB). Agent commissions: commission_entries (entry_id, agent_id, policy_id, commission_type NEW/RENEWAL, premium, rate, amount, earned_date).

API Design

• POST /v1/quotes — Generate an insurance quote; body contains product_type, risk_details (vehicle/property/person info), coverage_selections; returns quote_id, premium, coverages, available_discounts
• POST /v1/policies — Bind a quote into a policy; body contains quote_id, payment_method, effective_date; returns policy_id, policy_number, documents (declarations page PDF)
• POST /v1/claims — File a claim (FNOL); body contains policy_id, loss_date, loss_description, photos[]; returns claim_id, assigned_adjuster, next_steps
• POST /v1/policies/{policy_id}/endorsements — Apply a mid-term change; body contains changes (add vehicle, change address), effective_date; returns updated premium, pro-rata adjustment

Scaling & Bottlenecks

The Rating Engine is computationally intensive during quote surges (marketing campaigns can drive 10x normal quote volume). Rating table lookups involve many key-value lookups across multiple tables — this is optimized by caching the entire active rating table set in memory (typically 50-100MB per product) with cache invalidation on table updates. The engine scales horizontally as a stateless service behind a load balancer.

Renewal batch processing is the largest batch workload: 833K policies/month must be re-rated with current rating tables, underwriting rules re-evaluated, and renewal offers generated. This is parallelized across 50 workers processing by policy_id range, with each worker handling 16K renewals. The batch must complete within a 72-hour window to allow for 30-day advance renewal notice requirements. Claims photo processing (computer vision inference) is GPU-intensive — handled by auto-scaling GPU-equipped pods that scale based on the claims intake queue depth.

Key Trade-offs

• Event-sourced policies over CRUD: Event sourcing naturally handles backdated endorsements and provides complete audit trails required by regulators, but increases query complexity — materialized views for current state bridge the gap
• Configurable rating plans over coded algorithms: Actuaries can deploy rate changes independently of engineering, dramatically reducing time-to-market for rate filings — the trade-off is a more complex rating engine interpreter and harder debugging of pricing issues
• Automated claims adjudication over all-human review: Automation handles 60% of simple claims in minutes instead of days, but risks incorrect auto-approvals — confidence thresholds and random sampling audits provide quality control
• State-specific product configurations over one-size-fits-all: Insurance is regulated at the state level with vastly different rules — supporting 50 state configurations is operationally expensive but legally required