# yatinsharda/clearcheck architecture

> Architecture diagram of the GitHub repository yatinsharda/clearcheck, generated by GitDiagram from its file tree, README and a sample of source files (last updated 2026-09-26). It is an AI-made overview: check details against the source.

- Interactive diagram: https://gitdiagram.com/yatinsharda/clearcheck
- Repository: https://github.com/yatinsharda/clearcheck

## Overview

ClearCheck is a background-verification API for HR teams. An authorized client creates a case (with an idempotency key) or records a document check; the API manages the case lifecycle, persists case data and audit entries, and publishes case-update events for notification/reporting consumers. The README documents PostgreSQL, Redis, Kafka, role-based access, and Actuator health/readiness. No application source paths or excerpts are available, so runtime component paths are null and links reflect only documented relationships.

## Diagram (Mermaid)

```mermaid
flowchart TD

subgraph group_api["API and access"]
  node_case_api["Case API"]
  node_rbac["Role-based access"]
end

subgraph group_verification["Verification"]
  node_case_lifecycle["Case lifecycle"]
  node_document_checks["Document checks"]
  node_audit[("Audit trail")]
end

subgraph group_state["State and events"]
  node_postgres[("PostgreSQL")]
  node_idempotency[("Idempotency cache")]
  node_redis[("Redis")]
  node_case_event["Case-update event"]
  node_kafka["Kafka"]
  node_consumers["Notification/reporting consumers"]
end

subgraph group_operations["Operations"]
  node_actuator["Health/readiness endpoints"]
end

node_hr(("HR client"))

node_hr -->|"submits requests"| node_case_api
node_case_api -->|"applies roles"| node_rbac
node_case_api -->|"manages cases"| node_case_lifecycle
node_case_api -->|"records checks"| node_document_checks
node_case_api -->|"persists cases"| node_postgres
node_case_api -->|"checks retries"| node_idempotency
node_idempotency -->|"uses cache"| node_redis
node_case_api -->|"appends entries"| node_audit
node_case_api -->|"publishes update"| node_case_event
node_case_event -->|"sent via"| node_kafka
node_kafka -->|"dispatches to"| node_consumers
node_hr -->|"checks health"| node_actuator

classDef toneNeutral fill:#f8fafc,stroke:#334155,stroke-width:1.5px,color:#0f172a
classDef toneBlue fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#172554
classDef toneAmber fill:#fef3c7,stroke:#d97706,stroke-width:1.5px,color:#78350f
classDef toneMint fill:#dcfce7,stroke:#16a34a,stroke-width:1.5px,color:#14532d
classDef toneRose fill:#ffe4e6,stroke:#e11d48,stroke-width:1.5px,color:#881337
classDef toneIndigo fill:#e0e7ff,stroke:#4f46e5,stroke-width:1.5px,color:#312e81
classDef toneTeal fill:#ccfbf1,stroke:#0f766e,stroke-width:1.5px,color:#134e4a
class node_case_api,node_rbac,node_hr toneBlue
class node_case_lifecycle,node_document_checks,node_audit toneAmber
class node_postgres,node_idempotency,node_redis,node_case_event,node_kafka,node_consumers toneMint
class node_actuator toneRose
```

## Components

### API and access

- **Case API**
- **Role-based access**

### Verification

- **Case lifecycle**
- **Document checks**
- **Audit trail**

### State and events

- **PostgreSQL**
- **Idempotency cache**
- **Redis**
- **Case-update event**
- **Kafka**
- **Notification/reporting consumers**

### Operations

- **Health/readiness endpoints**

### Other components

- **HR client**

## Connections

- HR client → Case API: submits requests
- Case API → Role-based access: applies roles
- Case API → Case lifecycle: manages cases
- Case API → Document checks: records checks
- Case API → PostgreSQL: persists cases
- Case API → Idempotency cache: checks retries
- Idempotency cache → Redis: uses cache
- Case API → Audit trail: appends entries
- Case API → Case-update event: publishes update
- Case-update event → Kafka: sent via
- Kafka → Notification/reporting consumers: dispatches to
- HR client → Health/readiness endpoints: checks health