Tenant context is trusted
Policy, query, and persistence constraints with cross-tenant negative tests.
Supporting project · Backend reliability
Domain modernization plannedMulti-tenant Loyalty Platform
A legacy TypeScript backend being repositioned around its actual loyalty, coupon, and gift-card domain with tenant isolation and failure-safe workflows.
Engineering thesis
Reliability starts with domain truth.
The repository name reflects its history; the implementation's real domain is loyalty operations. The modernization makes that discrepancy explicit and targets trusted tenant context, constrained commands, persistence-level isolation, idempotent mutations, durable jobs, and complete audit history.
Duplicate delivery, partial failure, concurrent updates, token lifecycle, and recovery are treated as normal system behavior.
Target evidence
What the backend must prove
Mutations survive retries
Validated commands, idempotency keys, concurrency control, and transactional boundaries.
Jobs are recoverable
Outbox processing, duplicate delivery tests, retry limits, dead-letter behavior, and operator repair.
State change is explainable
Actor, tenant, command, transition, timestamp, correlation, and recovery history without leaking secrets.
Current boundary
The legacy name is not the product claim.
- The current repository is under domain and reliability modernization, not presented as a production-ready invoicing system.
- Multi-tenancy is accepted only when enforced and tested across every data access path.
- External notifications and scheduled work must fail safely and remain observable.