Claims system scaling and launch checklist

• Pagination: Policy, claim and audit lists use keyset pagination on (created_at, id) with filters on status and adjuster; no OFFSET.
• Caching: Rating tables are immutable by version and are cached by (table id) in memory; policy and claim detail are never cached across users.
• Idempotency: Payments, premium webhooks and FNOL submissions carry idempotency keys with unique constraints so retries never double pay or duplicate claims.
• Rate limits: Public FNOL is rate limited per IP and identity with a captcha fallback; quote API calls have per-key quotas.
• Data growth: audit_log and policy_versions grow monotonically; partition audit_log by month and keep policy_versions indexed by policy and date.
• Storage: Evidence files use presigned PUT into private buckets with lifecycle rules per retention class; reads are signed and short lived.

• Metric claims open by status: by adjuster team and age bucket.
• Metric payment approval latency: time from request to approval by band.
• Log claim audit log: request id, actor, claim id, action; personal fields excluded.
• Trace payment trace: request, authority check, approval, payout, ledger entry.
• Slo payment correctness: zero double payments and zero payments without a distinct approver.
• Alert audit chain break: any verification failure pages immediately.
• Alert lapse job stalled: dunning job not completing within its schedule window.

• premium_schedule_and_dunning: runs cron daily. Guard: idempotent per (invoice, step); grace and lapse transitions recorded in the audit log.
• renewal_reminders: runs cron daily. Guard: one task per (policy, threshold).
• scan_documents: runs queue (jobs) on upload. Guard: no download until clean; size cap; retries bounded.
• claim_diary_notify: runs cron hourly. Guard: one notification per diary item.
• run_fraud_rules: runs queue (jobs) on claim create or party change. Guard: flags only; idempotent per (claim, rule).
• build_bordereaux: runs queue (jobs) on request. Guard: snapshot of a closed period, checksum stored, no mutation after lock.

• Read replicas: Loss-ratio and bordereaux reports run on a read replica when primary CPU > 60% sustained; claim handling uses the primary.

Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

Every metered resource on Forge64 has a hard cap, so a traffic spike stops at your limit instead of becoming a surprise bill. This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.

When should I worry about scale for a claims system?

Not before a measured trigger fires. For example, for "ACORD/partner message adapters": first partner integration contract.

What performance targets should a claims system aim for?

Quote rating: p95 < 400 ms for up to 40 rating factors. Claim file load: p95 < 500 ms with 200 documents listed lazily. Payment request: p95 < 300 ms including approval-rule evaluation.

Does Forge64 cap my usage costs?

Yes. Every metered resource has a hard cap, and paid plans add an overage spend cap that you set.

• How to build a claims system
• Claims system architecture
• Example prompt for a claims system
• Claims system security checklist
• Often combined: accounting system
• Often combined: approval workflow app
• All app types