13 - FAQ & Glossary

The separation forces the business logic in Application to be independent of infrastructure decisions (DB, external APIs, queues). You can swap PostgreSQL for SQL Server, or Kafka for RabbitMQ, without touching Application code. Tests can mock interfaces without hitting a real DB.

The project uses Command and Result DTOs but calls services directly instead of going through MediatR. This is a deliberate simplification - fewer layers, easier to trace, no magic pipeline behaviors. If you need pipeline behaviors (logging, validation, transactions), they are handled by middleware, filters, and EF Core SaveChanges already.

Frontend has setState-based architecture where one ApiService exposes all endpoints. Backend has stage-specific services because each stage has non-trivial business logic (validation, state transitions, provider orchestration, downstream events). Splitting on the backend keeps each service under 500 lines.

PAN verification is regulated and must work 100% of the time. MOSL has commercial relationships with multiple providers (Zintlr for phone-to-PAN lookup, Hyperverge and NSDL for direct verify, UTI and CVL KRA as fallbacks, NDML for edge cases). The provider chain executor tries them in configured priority order until one succeeds.

By running it in the background right after OTP verification, the bank details are typically ready by the time the user reaches Stage 6. This creates a seamless "We found your bank account" experience where the user just confirms instead of typing account details. If Decentro fails or returns a non-active-savings account, the user falls back to the normal UPI / manual flow at Stage 6.

Each verification stage has its own attempt / result table for auditability. Plus 22 reference master tables (states, cities, pincodes, bank IFSC codes, KRA error codes, etc.) that are loaded from external sources. Plus admin / audit / config tables. The count is high but each table is small and focused.

The project currently uses code-first configurations but has not generated migration files. The schema is created via EntityTypeConfiguration classes in OnModelCreating. For production, you will need to run dotnet ef migrations add InitialCreate and then incrementally for each change. See 12 - How-To Guides.

From the existing MOSL data lake and legacy systems - not from the new eKYC backend itself. Tables like client_master, branch_master, employee_pan_master are daily syncs from back-office. bank_ifsc_masters is synced from RBI. negative_list_entries is synced from SEBI. See the Sync Tables Master List and 10 - Database.

The Redis NuGet is present for future use but the current cache implementation is InMemoryCacheService. This keeps local dev simple (no Redis instance needed) and the cache is not yet used for cross-instance state. When production needs a distributed cache, swap the DI registration to a Redis-backed implementation without changing consuming code.

PostgreSQL convention and matches existing MOSL DB naming. EFCore.NamingConventions automatically translates C# PascalCase properties to snake_case columns (LeadId → lead_id, CurrentStage → current_stage).