Community Platform
An Alumni Network That Doesn't Feel Like Yet Another Facebook Group
Jobs, posts, messaging, mentorship discovery, and an institution directory. Built so multiple institutions can run their own community on one platform.
Every institution wants an alumni network. Most settle for a WhatsApp group and a Facebook page. The serious ones spin up a LinkedIn group, which works for posting but fails at everything else.
The brief was a real alumni network. Multi-institutional, with a directory, jobs board, social feed, real-time messaging, and an admin layer that lets each institution run its own community without engineering involvement.
What we built
1. Social feed with the basics that matter
Posts, likes, comments, shares. Mentions of other alumni. Images and links inline. No reinventing the timeline, just executing it properly.
- Post composer with image and link support
- Likes, comments, shares, mentions
- Per-institution and global feeds
- Moderation actions exposed to institution admins
2. Real-time messaging
One-to-one and small group chat. Presence indicators, typing notifications, push to mobile when offline. Good enough that members do not fall back to WhatsApp.
- WebSocket-backed direct messaging
- Group chats with up to a small fixed cap
- Push notifications for offline users
- Read receipts and typing indicators
3. Jobs board
Members post jobs. Other members apply. The board doubles as the career signal an alumni network is supposed to generate. Designation, company, and skills tags help the right people find the right roles.
- Job posting with designation and skill tagging
- Application flow with resume upload
- Company directory linked to job posts
- Saved searches for new postings in a category
4. Directory and discovery
Find alumni by institution, degree, batch year, current company, skills. Endorsements on skills give weight to the discovery signal. Cities and locations help the local meetups happen.
- Institution and degree directory
- Company and current-role directory
- Skill endorsement system
- City-based discovery for local meetups
5. Admin moderation per institution
Each institution runs its own community. Admins approve members, moderate posts, manage the institution directory, and push announcements. Cross-institution moderation belongs to the platform team only.
- Per-institution admin roles
- Member approval workflow
- Post and comment moderation queue
- Announcement broadcasts to institution members
Tech stack and why we chose it
Community platforms have two distinct data shapes. Profiles and relationships look relational. Feed events and chat look append-only and document-shaped. We picked stores accordingly.
- FastAPI on the backend. One API surface for both the relational and document-shaped reads. Async by default, which mattered for the WebSocket workload running next to the regular REST endpoints.
- PostgreSQL for profiles, institutions, jobs, skills, and endorsements. Anything where a foreign key is the right primitive lives here. SQLAlchemy ORM with Alembic migrations to keep schema changes safe.
- MongoDB for the social feed and chat history. Posts are append-mostly with variable shape per post type. A relational schema would have required either a wide nullable table or a join nightmare. Document storage fits the shape.
- WebSocket for chat. One process holds connection state in memory with Redis pub-sub for cross-instance broadcast. The chat is the highest concurrency surface so it gets its own scaling profile.
- Firebase Cloud Messaging for push. Mobile members do not stay in the app, so push is how they come back. FCM is free at this scale and reliable on both iOS and Android.
- Next.js for the web frontend. Server components for the feed view so the initial scroll is fast even on slow connections. App Router for everything else.
- Cloudinary plus Cloudflare R2 for media. Cloudinary handles the on-the-fly resize and crop for avatars and post images. R2 holds the bulkier original uploads with zero egress fees.
Outcome
Live across institutions. The shape of the data, multi-database backend with WebSocket and REST on the same FastAPI process, has held up under real load.
Frequently asked questions
Why two databases instead of one?
Each store does what it is good at. Postgres is unbeatable for the relational shape of profiles, institutions, and jobs. MongoDB is unbeatable for the append-mostly, variable-shape feed and chat data. Forcing one to do both jobs would have cost us either schema agility or relational integrity, neither of which we wanted to trade.
How does cross-institution moderation work?
Institutions moderate their own communities. The platform team handles cross-institution disputes and the rare member who needs to be banned across the whole platform. Both roles are gated by distinct scopes in the JWT.
Can members belong to multiple institutions?
Yes. A user record carries a list of verified institution affiliations, so a member who did undergrad at one place and a graduate program at another shows up in both directories. The feed surface aggregates posts across all their affiliations by default.