Skip to main content

State Management & End-to-End Data Flow

This document details how data flows through veridex-hitech-web-application, from user interaction and client-side form state through Server Actions, rate limiting, validation, MongoDB persistence, and external service synchronization.

1. State Management Architecture​

Rather than relying on heavyweight global state libraries (such as Redux or MobX), the platform adopts a modern, lightweight state architecture aligned with React 19 and Next.js 15:

1.1 State Categories​

  1. Server-Rendered Page State: Handled via Server Components. Initial data (e.g. blog posts, dynamic FAQs) is passed directly down component trees as typed props.
  2. Form Mutation State: Managed via React 19's useActionState hook. Tracks isPending, validation errors, and server return values without requiring manual try/catch or intermediate loading state variables.
  3. Authentication State: Provided by <AuthProvider> (SessionProvider wrapper) allowing client components to access user credentials, role, and referral code via useSession().
  4. Transient Client State: Managed by useState for UI concerns such as step progression in the 16-step auto questionnaire, image cropping zoom levels, and modal visibility.

2. Inbound Lead Data Flow & Draft Autosave Pipeline​

To minimize drop-off on complex commercial and personal insurance applications, the platform implements an atomic two-step draft-and-complete data flow:

3. Telemetry & Visitor Journey Data Flow​

Visitor engagement and conversion telemetry execute non-blocking, privacy-preserving tracking without third-party tracking cookies:

4. Bulk Email Broadcast Data Flow​

The mass communication pipeline processes campaigns through managed micro-batches to guarantee high deliverability:

  1. Composition & Asset Offloading: The administrator composes the email in Tiptap. Uploaded images are offloaded via uploadInlineEmailImageAction into the Signature collection, substituting /api/signatures/[id] URLs to maintain lightweight template documents.
  2. Recipient Chunking: Recipients from manual inputs or CSV uploads are divided into chunks and stored in BulkEmailRecipientChunk ({ campaignId, chunkIndex }), mitigating the 16 MB BSON document limit.
  3. Controlled Micro-Batch Dispatch:
    • Emails are dispatched in batches of 5 (BATCH_SIZE = 5).
    • An artificial delay of 250ms (BATCH_DELAY_MS = 250) is enforced between batches.
    • Individual recipient success/failure is recorded in real time.
  4. Audit Trail Logging: Once complete, an immutable summary record is logged in AdminAuditLog recording the administrator identity, subject line, recipient count, and timestamp.