How We Built a Real-Time Claims Dashboard: Architecture Decisions in React and Spring Boot

Building a real-time claims dashboard isn't complicated until it is. The moment you add live data feeds, multi-role access, and audit requirements, every architectural shortcut you took in week one becomes a problem in week six. Here's what we learned building IRD ClaimsDash for an insurance operations client.

The Core Problem

Claims adjusters, supervisors, and compliance teams all need to see claim status — but they need different views, different permissions, and different data freshness. A supervisor watching a queue of 200 open claims needs updates every 30 seconds. A compliance officer pulling a historical audit trail can wait. Treating them the same kills performance and wastes infrastructure budget.

Frontend: React with a Polling Architecture (Not WebSockets)

The instinct is to reach for WebSockets for anything "real-time." We didn't. For insurance dashboards, the data update frequency is predictable and moderate — claims don't change 10 times per second. WebSockets add connection state complexity, reconnection logic, and backend infrastructure overhead that isn't justified when smart polling does the job cleanly.

We used React Query with configurable refetch intervals per role. Adjusters get a 30-second refresh cycle. Supervisors get 15 seconds. Compliance views are effectively static with manual refresh. This single decision reduced backend load by roughly 40% compared to our initial WebSocket prototype, with no perceptible difference for end users.

Role-based views were handled at the component level using a context provider that reads from the authenticated session. No route duplication — one dashboard shell, conditional rendering based on role.

Backend: Spring Boot with Async Processing

Spring Boot's @Async support was central to keeping the API responsive. When a claim status change triggers downstream notifications — adjuster alerts, supervisor queue updates, audit log writes — none of that happens synchronously in the request thread. Those tasks get dispatched to an async executor pool and the API responds immediately.

For the audit trail specifically, we used Spring's @Transactional with careful thought about what needed to be in the same transaction versus what could be eventually consistent. Claim status updates: transactional. Notification dispatch: eventual. Audit writes: transactional but on a separate write path. Getting this boundary right is the difference between a system that scales and one that deadlocks under load.

The Permission Layer

Spring Security with method-level @PreAuthorize annotations. Every service method that touches claim data is annotated with the required role. This keeps authorization logic out of controllers and in the domain layer where it belongs. If a new API endpoint gets added, it inherits the security model automatically — there's no checklist to remember.

What We'd Do Differently

We initially built the filter and search layer in the frontend using client-side filtering on a paginated response. That breaks the moment the dataset grows past a few thousand records. We refactored to server-side filtering with Spring Data JPA Specifications midway through — which was the right call, just later than it should have been. Build server-side filtering from day one.

The Takeaway

Real-time for enterprise doesn't mean "as fast as physically possible." It means fast enough for the workflow, reliable enough for compliance, and simple enough to maintain. Those three constraints together usually point away from the flashy solution and toward the boring one that works.

IRD ClaimsDash is available as a customizable accelerator for insurance and healthcare operations teams. Get in touch if your claims operations need a modern interface on top of legacy data.