Data Model

Data Model

This section provides an overview of the core data entities, their attributes, and relationships within the faizanGeek/ClaimProcessingSystem. Understanding this data model is fundamental to comprehending how claims are processed, users are managed, and system insights are generated.

The system primarily utilizes a relational database for persistent storage of transactional data (like User and Claim entities). Additionally, it leverages Redis for high-speed caching of frequently accessed data and Kafka for real-time, asynchronous notification messaging.

Core Entities

1. User

The User entity represents an individual user interacting with the system. Users can submit claims, receive notifications, and have different roles and statuses within the application.

| Attribute | Type | Description | | :------------- | :------- | :------------------------------------------------------------------------ | | userId | Long | Unique identifier for the user. | | username | String | Unique username used for login. | | email | String | User's email address, primarily used for notifications and communication. | | passwordHash | String | Hashed password for secure authentication (internal to UserService). | | role | String | User's role (e.g., "admin", "claimant"). | | status | String | Current status of the user's account (e.g., "active", "inactive"). | | createdAt | Date | Timestamp indicating when the user account was created. | | lastLogin | Date | Timestamp of the user's last successful login. | | updatedAt | Date | Timestamp of the last update to the user's profile details. |

Relationships:

• One-to-Many with Claim: A single User can be associated with multiple Claim entities, representing the claims they have submitted.

2. Claim

The Claim entity is central to the system, representing a request for compensation or service submitted by a user. It tracks all essential details and the processing status of a claim.

| Attribute | Type | Description | | :------------ | :------- | :------------------------------------------------------------------------ | | claimId | Long | Unique identifier for the claim. | | user | User | The User entity representing the claimant. | | claimDate | Date | The date when the claim was originally submitted. | | claimAmount | Double | The monetary value associated with the claim. | | claimType | String | The category or nature of the claim (e.g., "Medical", "Automotive", "Property"). | | claimStatus | String | The current processing status of the claim (e.g., "Submitted", "Pending", "Processed", "Approved", "Rejected"). This status is also cached in Redis for quick retrieval using the key claimStatus:<claimId>. | | lastUpdated | Date | Timestamp of the most recent update to the claim's details or status. | | emailId | String | The email address associated with the claim, often mirroring the user's email, used primarily for targeted notifications. |

Relationships:

• Many-to-One with User: Each Claim is submitted by and linked to a single User.

3. Notification Messages (Kafka DTOs)

The system utilizes Kafka for asynchronous, real-time communication of events and notifications. These are represented by Data Transfer Objects (DTOs) rather than persistently stored database entities.

a. ClaimStatusUpdateMessage

This DTO is used to publish messages to Kafka whenever a claim's status is updated. Consumers can then react to these updates (e.g., sending email notifications).

public class ClaimStatusUpdateMessage {
    private Long claimId;
    private String newStatus;
    private String userEmail;

    // Constructors, getters, setters
}

b. NotificationDTO

A more generic DTO used for broader user notifications, such as subscription management or general alerts.

public class NotificationDTO {
    private Long id; // May be null for new messages
    private Long userId;
    private String message;
    private Date timestamp;

    // Constructors, getters, setters
}

Usage:

• These DTOs define the contract for data exchanged via Kafka topics (claim-status-updates, user-notifications, unsubscribe-notifications), enabling loose coupling between services.

4. Reporting Entities

Reporting entities store aggregated or summarized data derived from transactional entities, primarily Claim, to facilitate efficient generation of reports and dashboards. These are often updated periodically or on demand.

a. ClaimReport

Represents statistical summaries of claims, typically grouped by status.

| Attribute | Type | Description | | :----------------- | :------- | :---------------------------------------------- | | claimStatus | String | The claim status category for this report entry. | | totalClaims | Long | The total number of claims within this status. | | totalClaimAmount | Double | The sum of claim amounts for all claims in this status. |

b. ClaimsSummary

Provides an overall summary of all claims processed by the system at a specific point in time.

| Attribute | Type | Description | | :---------------- | :------- | :---------------------------------------------- | | reportGenerated | Date | Timestamp when this summary report was generated. | | numberOfClaims | Long | Total number of claims in the system. | | totalAmount | Double | The sum of all claim amounts across the system. |

Usage:

• These entities are utilized by the ReportService to provide quick access to aggregated data, avoiding complex queries against the primary transactional tables for reporting purposes.

Entity Relationship Summary

The key relationships within the Claim Processing System's data model are:

• User (1) <---> (M) Claim: A user can submit multiple claims, but each claim is associated with one specific user.
• Claim --- (triggers) --- ClaimStatusUpdateMessage: Changes to a Claim's status trigger the publication of a ClaimStatusUpdateMessage to Kafka, leading to notifications.
• User --- (related to) --- NotificationDTO: NotificationDTOs are sent via Kafka for user-specific events, such as subscriptions, often referring to a userId.
• Claim --- (derives) --- ClaimReport, ClaimsSummary: The reporting entities are aggregated views or summaries calculated from the underlying Claim data.