Multi-Tenant Per-Case Databases¶
Principle¶
Each case (matter) in the Nextpoint platform gets its own MySQL database schema. A shared "core" database holds cross-case data (case metadata, user accounts).
Why Per-Case Schemas¶
- Data isolation — litigation data is sensitive. Per-case schemas provide strong isolation without application-level row filtering.
- Performance — queries never need a
WHERE case_id = ?filter. Indexes are smaller and more efficient. - Lifecycle management — when a case is closed, its schema can be archived or dropped without affecting other cases.
- Compliance — data retention and deletion requirements can be applied per-case.
How It Works¶
RDS Cluster
├── nextpoint_core # Shared: cases, users, accounts
├── nextpoint_case_1001 # Case-specific: exhibits, batches, tags
├── nextpoint_case_1002 # Case-specific: exhibits, batches, tags
└── nextpoint_case_1003 # ...
Database Naming Convention¶
Session Types¶
writer_session(npcase_id)— write to case-specific databasereader_session(npcase_id)— read from case-specific database (read replica)core_writer_session()— write to shared core databasecore_reader_session()— read from shared core database (read replica)
Connection Management¶
- Read/write separation via RDS Proxy endpoints (writer vs reader)
- Connection pooling with SQLAlchemy engine cache (max 50 engines, LRU eviction)
- Pool configuration: 5 base connections, 5 overflow, 60s timeout, 30min recycle
- Pre-ping enabled to validate connections before use
- READ COMMITTED isolation for writer sessions
Constraints¶
- Lambda functions must set
npcase_idcontext before any database operation - Never hardcode database names — always derive from
RDS_DBNAME+case_id - Core database operations use separate session types (
core_reader_session()) - Engine cache prevents connection exhaustion across concurrent Lambda invocations
Ask the Architecture
×
Ask questions about Nextpoint architecture, patterns, rules, or any module. Powered by Claude Opus 4.6.