Backend

Event-Driven Insurance Claims Platform

Kafka-driven claim processing benchmarked up to 1M events/day, with Elasticsearch search that cut query latency by 40%.

Java
Spring Boot
Hibernate
PostgreSQL
Kafka
Elasticsearch
Docker

The code is not public yet and is available on request. Request the code

Results

1M
events/day in benchmarks
40%
lower query latency with Elasticsearch
3
services: policy, claim, search

Problem

Insurance claims touch policy, claim, and search data and move through several processing steps. The goal was to keep claim intake responsive while processing scales, and to make claims fast to search.

My role

Solo project. I designed and built the Spring Boot services, the Kafka event flow, the Elasticsearch search path, and the integration tests.

Architecture

Services publish and consume claim events; PostgreSQL is the record, Elasticsearch serves search. Open full size Open full size

Diagram source (Mermaid)

flowchart TD
  C["Client"] --> PS["Policy service (Spring Boot)"]
  C --> CS["Claim service (Spring Boot)"]
  C --> SS["Search service (Spring Boot)"]
  CS -->|"claim events"| K[["Kafka"]]
  K --> CP["Claim processing consumers"]
  PS --> DB[("PostgreSQL via Hibernate")]
  CS --> DB
  CP --> DB
  DB -.->|"indexed for full-text search"| ES[("Elasticsearch")]
  SS --> ES

Key decisions and tradeoffs

Events between services: The claim service publishes events to Kafka and consumers process them, so intake stays responsive while processing scales on its own.
Separate read model for search: PostgreSQL stays the source of truth. Elasticsearch holds a search-optimized copy for full-text queries, which is where the 40% latency cut came from.
Integration tests over mocks: End-to-end workflows were validated with integration tests, because the risky parts are the boundaries between services, the broker, and the stores.

What I'd improve next

Add a dead-letter topic and replay tooling for failed claim events.
Record a short walkthrough of a claim moving from intake to search.