CampusLoop — Architecture of a Verified Student Social Network
Building verified, institutional email-gated campus feeds, peer marketplaces, real-time polls, and encrypted batch time capsules across Indian universities.
1,350+
Colleges in Directory Schema
PWA + Edge
Client Architecture
PostgreSQL
Multi-Tenant Isolation
1. The Core Problem & Trust Model
Mainstream social networks fail campus communities because they lack trust boundaries: public platforms invite external harassment, while WhatsApp/Telegram groups lack anonymity and break down past a single batch.
CampusLoop solves this via strict .edu / .ac.in email verification paired with cryptographic pseudonymous posting keys. Students get a private, authentic campus commons.
TODO(shaswat): What exact authentication handshake and token verification flow is used for institutional email verification?2. Schema & Data Model Decisions
Multi-tenancy was structured around college domain tenants with strict row-level segregation:
- Tenant Partitioning: Every feed post, canteen poll, and marketplace listing is bounded by
college_idforeign key partitions. - Decoupled Identity: User profiles maintain verification status separately from feed author identifiers to prevent de-anonymization attacks.
TODO(shaswat): Provide the key Prisma/PostgreSQL schema definitions and indexing strategies for the campus feed and poll models.3. Hardest Scaling or Correctness Problem
Preventing race conditions during high-concurrency campus voting and real-time feed updates:
TODO(shaswat): Describe the hardest engineering bug or concurrency issue faced (e.g. double voting prevention, WebSocket reconnect storms, or feed cache invalidation).4. One Tradeoff I'd Reverse
Reflections on early architecture vs production reality:
TODO(shaswat): What architectural or state management tradeoff in CampusLoop would you reverse today (e.g., choice of real-time protocol, caching layer, or client state)?