graph TD
%%{init: {'theme':'dark','themeVariables':{'primaryColor':'#0d0f1a','secondaryColor':'#131627','tertiaryColor':'#06070d','borderRadius':'10px','fontSize':'12px','primaryTextColor':'#e2e8f0'}}} %%
subgraph M["Mobile Layer"]
direction TB
RN["React Native\niOS + Android"]
Portal["React Admin\nPortal"]
end
subgraph B["Backend"]
direction TB
API["FastAPI\nREST + GraphQL"]
FA["FAISS\nFace Verification"]
end
subgraph I["Infrastructure"]
direction TB
K8S["Kubernetes\nAuto-scaling"]
DB["PostgreSQL\n+ Redis"]
ML["MLflow\nObservability"]
end
RN -->|API calls| API
Portal -->|Admin API| API
API -->|Face vectors| FA
API -->|Orchestration| K8S
FA -->|Vectors| DB
K8S -->|Persist data| DB
K8S -->|Metrics| ML
classDef default fill:#0d0f1a,stroke:#00e5ff,stroke-width:1px
classDef accent fill:#131627,stroke:#7c3aed,stroke-width:1px
classDef warn fill:#131627,stroke:#f97316,stroke-width:1px
class FA accent
class K8S warn
QARD — End-to-End Case Study
Problem
Universities issued physical student IDs, creating daily on-campus verification queues, replacement fees for lost cards, and fraud that manual checks could not catch at scale. Each institution also needed its own branded, isolated system, so any rebuild would be duplicated per school.
Approach & Architecture Decisions
Built a multi-tenant SaaS on FastAPI with strict per-university tenant isolation (separate schemas, branding, and admin portals). Face verification uses FAISS vector matching: student selfies are encoded to vectors and matched against registered profiles. Deployed on Kubernetes with auto-scaling to hold 99.5% uptime across 5+ university clusters. Payments wired through Stripe and JazzCash for local Pakistani transactions.
The React Native app (iOS + Android) handles real-time face capture, while a React admin portal lets university staff manage enrollment, branding, and benefits from one dashboard. MLflow tracks model versioning and verification metrics.
Key Tradeoff
Chose self-hosted FAISS over managed vector search for lower per-query cost and full data control, but had to build our own vector scaling and index-update pipeline. Multi-tenant Kubernetes (rather than one cluster per university) kept infra lean across 5+ schools, but made tenant-isolation testing more involved.
Result & Metrics
- 500+ students enrolled across 5+ universities
- 99.5% uptime with auto-scaling on Kubernetes
- 50+ ID verification requests processed per week
- Eliminated physical ID card queues campus-wide
500+ students now carry verified IDs on their phones instead of physical cards, eliminating campus-wide ID queues across 5 university rollouts. University admin teams manage enrollment, verification, and benefits from a single dashboard.
What I'd Do Differently
Scaling to 5+ universities surfaced tenant-isolation edge cases late in the build. Next time I would extract the tenant boundary into a dedicated service layer before the third university, so new schools add configuration rather than code changes.
