Design a College Alumni Networking Platform

Problem statement

Design a college alumni networking platform that connects graduates of the same institution across graduating classes and academic majors. The product must verify that a person actually attended or graduated, organize members into class-year cohorts and major-based subgroups, surface alumni job postings and mentorship opportunities, and expose a searchable directory whose contact details each member controls.

The brief pins four functional requirements and four non-functional requirements. Functional: verify alumni via email domain or transcripts; build class-year groups with major subgroups; host job postings and recommended mentorship; provide a directory with contact preferences. Non-functional: privacy controls for members who want to stay private; scale for large universities; search by graduation year, major, and location; moderation to enforce community standards.

Why this is not LinkedIn or Facebook

A generic professional network optimizes for maximum graph growth and engagement. An alumni network optimizes for trust and belonging within a bounded, verifiable community. That single difference changes the entire architecture. The scarce resource here is not attention but authenticated identity. Every downstream feature — directory search, mentorship matching, job referral — is only as valuable as the confidence that the person on the other end actually shares the institution.

Three properties make this distinctive:

1. Identity is gated, not open. Admission requires proof (a university email domain, an SSO assertion from the university identity provider, or a reviewed transcript). Verification is a first-class subsystem with its own state machine, not a checkbox on signup.

1. Time is a first-class partitioning dimension. Class year and major create a multi-dimensional community lattice. A member belongs to the Class of 2015, the Computer Science cohort, and possibly a regional chapter. Queries like 'Class of 2012, Mechanical Engineering, in Chicago' are filtered graph lookups, not full-text search.

1. Privacy is heterogeneous and field-level. Some alumni want to be found by recruiters and old friends; others want to be invisible except to their own class year; some opt out entirely. Visibility must be evaluated per field, per viewer, at query time. This is the hardest correctness problem in the system, because a search index that leaks a private field is a privacy incident, not a bug.

The four architectural planes

1. Trust plane: verification workflows, trust levels, evidence retention, fraud signals, and re-verification.
2. Graph plane: the member directory, class/major cohort membership, connection edges, and visibility rules.
3. Engagement plane: feed posts, job postings, mentorship matching, events, RSVPs, and messaging.
4. Governance plane: moderation, policy configuration, audit, compliance (FERPA, GDPR, CCPA), and per-university administration.

A strong answer keeps these planes separate. The engagement plane may degrade during a traffic spike, but the trust plane must never be relaxed to reduce friction, and the governance plane must be able to freeze an account without taking down the directory.