Designing a Professional Network: People, Connections, and Feeds
Algomi Research · Created 2026-09-16 · Updated 2026-10-15 · System Design
Imran wants his next job
Imran is a junior Java developer in Indore. He joins KaamJodo, a professional network: he fills in his profile, connects with old classmates, follows a few companies, posts about a side project, and messages a recruiter. (Imran, KaamJodo, Pooja and every number here are made up for teaching.)
Pooja is KaamJodo's architect. Picture a school club directory where members describe their interests, connect with classmates, share updates and find projects. A professional network is that idea at a much larger scale: profiles, relationships, posts, opportunities and messages.
This guide designs a LinkedIn-like service for an interview. It does not describe LinkedIn's internal architecture. The useful challenge is deciding which information must be correct immediately, and which can appear a little later.
| What happens to Imran | Idea it forces |
|---|---|
| "Imran and Divya ended up connected twice" | Model each relationship precisely |
| "He changed his title, but search shows the old one" | Search is a projection that lags |
| "His post reached 300 people; the CEO's reached 2 million" | Fan-out on write vs read, the hybrid |
| "A recruiter he blocked still saw his post" | Recheck visibility at read time |
| "His message to the recruiter was sent twice" | Idempotent messages |
| "A random employee edited his company's job post" | Scoped roles |
In 30 seconds, as an architect would frame it: "Authoritative data (members, connections, posts, messages, jobs) lives in a relational store, with relationships modelled by direction: a normalised unique pair for connections, a directed unique pair for follows. Each committed change writes an outbox event, and consumers build projections: a search index and per-member feed lists holding references, not copies. Feeds use a hybrid: fan-out on write for ordinary authors, fan-out on read for huge audiences. Projections can lag, so visibility and blocks are rechecked at read time."
1. The first version, over one database
Scope: profiles, connection invitations, follows, posts, a home feed, member search and basic private messages. Company pages, job listings, groups and notifications are separate capabilities with clear owners. A full recommendation engine is out of scope for version one.
Ask first: profile visibility rules, expected relationships per member, feed freshness and message delivery requirements. A network with a few thousand members doesn't need the infrastructure of one with hundreds of millions.
Pick stores by query:
- A relational database for authoritative members and relationships.
- A search index for discovery.
- A cache or derived store for feeds.
"Put everything in a graph database" isn't a substitute for looking at the access patterns.
You've reached the free preview of this post.
Subscribe to the Blogs plan (₹99/mo) — or use any Algomi Suite, Career, Investor, or Trader plan — to keep reading.
See plans