feat: Implement user mapping layer using H2 in memory database

[paradyo]

Description

1 lightweight user mapping layer must be implemented using the H2 in memory database to associate Clerk user identifiers with internal system user records. The backend must store Clerk user IDs and map them to corresponding internal user data when required for application logic. This ensures authenticated requests using Clerk tokens can be linked to internal system users without introducing a persistent external database dependency.

Ownership, Timeline, and Effort

Owner: @cenkerenozbek
Given Date: 04-03-2026
Deadline: 08-03-2026 24:00 (end of day, explicitly stated)
Hours: 1
Value: 1
Week: 10

Deliverables

• H2 in memory database schema created for user mapping.
• Data model implemented to store Clerk user identifiers and corresponding internal user references.
• Backend service logic implemented to read and write user mappings.
• Backend request processing capable of resolving internal user records using Clerk user identifiers.
• Pull request containing user mapping implementation merged into the main branch.

Scope Definition

In Scope

• Configure H2 in memory database usage for user mapping.
• Create schema or table structure to store Clerk user identifiers.
• Implement mapping between Clerk user identifiers and internal user records.
• Implement service layer logic to retrieve internal user data using Clerk identifiers.
• Enable request processing to associate authenticated users with internal records.
• Submit pull request implementing the mapping layer.

Out of Scope

• Persistent database storage outside the H2 in memory database.
• Migration to external database systems.
• Role based authorization or permission management.
• User profile management features.
• Changes to frontend authentication or identity handling.

Acceptance Criteria

• H2 in memory database contains a table for mapping Clerk user identifiers.
• Backend can store mappings between Clerk user IDs and internal user records.
• Backend services can retrieve internal user records using Clerk identifiers.
• Authenticated requests correctly associate with internal user data when available.
• System continues functioning without external persistent database dependencies.
• Pull request implementing the mapping layer is merged into the main branch.

Domain Specific Notes

Engineering considerations:

• The mapping layer must rely on Clerk user identifiers obtained from verified authentication tokens.
• H2 database usage must remain lightweight and suitable for in memory operation.

Assumption: Authentication middleware already provides verified Clerk user identifiers in the request context.

Validation and Review Requirements

• Reviewer verifies H2 database schema exists for user mapping.
• Reviewer confirms Clerk user identifiers can be stored and retrieved.
• Reviewer validates that authenticated requests correctly resolve internal user records.
• Reviewer confirms the system operates without requiring external database persistence.
• Issue is considered Done only when the pull request implementing the user mapping layer is merged into the main branch.