Design a Hobby Group Aggregator

Medium45 min
1 / 30
understanding•10 min read

Problem Statement: Aggregating a Long Tail of Micro-Communities

Frames the product as a discovery-first aggregator over hundreds of thousands of small hobby groups, not a single social network.

Problem statement

Design a Hobby Group Aggregator: a platform that aggregates smaller hobby groups and clubs — crocheting circles, hiking crews, book clubs, board-game nights, amateur astronomy societies — so that users can discover them, join them, attend their events, and participate in their discussions. The product overlaps with Meetup but is broader: it aggregates groups that may originate on our own platform and from external community sources, normalizes them into one catalog, and ranks them for each user by interest, location, and activity.

The defining property of this problem is the long tail of micro-communities. A mainstream social network optimizes for a small number of very large audiences. A hobby aggregator optimizes for the opposite shape: roughly 1.8 million groups in our design assumptions, with a median membership of about 12 people and more than 90% of groups below 50 members. Discovery, search, and recommendations must work just as well for a 9-person urban foraging club as for a 40,000-member photography community. This power-law distribution drives nearly every architecture decision: fanout strategy, index design, counter consistency, and moderation staffing.

Why the problem is distinctive

A feed system can tolerate stale counts. A group discovery system cannot tolerate groups that are invisible, duplicated, dead, or unsafe. The design therefore separates catalog correctness from engagement performance. Catalog correctness means: every real group is findable, duplicate listings from different sources are merged into one canonical page, stale or abandoned groups are demoted rather than deleted, and categories and tags are consistent enough to facet on. Engagement performance means: feeds, search, and recommendations respond in tens of milliseconds even though the underlying catalog changes constantly.

The brief requires group creation by hobby or interest, group pages with upcoming events and discussions, user discovery and recommendation of new groups, membership requests or invites, categorization and tagging, scalability for many micro-communities, search by location and hobby, and moderation or group admin tools. The section rhythm, recap contract, quiz placement, multi-cloud diagrams, and WinSystemDesign Friend rules follow the attached orchestrator and master prompt, while the schema, phase vocabulary, and 30-section pacing follow the course profile.

Public operating baseline versus design assumptions

Public evidence establishes that this category is operationally real at scale. Meetup publicly reports a network on the order of tens of millions of members and hundreds of thousands of active groups, and its engineering blog documents a GraphQL gateway, Kafka event backbone, and Elasticsearch-driven geo search. Discord reports over 200 million monthly active users and has published how it stores trillions of messages in ScyllaDB. Reddit reports roughly 52 million daily active users across more than 100,000 active communities. These are cited company figures, used as calibration anchors, not as requirements for our fictional system.

For capacity planning, this answer explicitly assumes a mature platform with 60 million registered users, 12 million monthly actives, 2.5 million daily actives, 1.8 million groups, 900,000 events per month, and a five-times event peak. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold.

The four architectural planes

  1. Catalog plane: groups, categories, tags, entity resolution across ingested sources, canonical pages, freshness.
  2. Engagement plane: memberships, feed generation, discussions, events, RSVPs, notifications.
  3. Discovery plane: search, geo facets, recommendation candidate generation and ranking, personalization.
  4. Trust plane: permissions, group admin tools, reports, enforcement, appeals, audit.

A strong interview answer keeps these planes separate. Discovery may degrade without breaking the catalog, engagement may lag without corrupting membership truth, and trust actions must never be silently undone by a cache rebuild.

Key Highlights

  • •The product is discovery-first over a long tail: ~1.8M assumed groups with a median membership of ~12.
  • •Catalog correctness (findable, deduplicated, current, safe groups) is separated from engagement latency.
  • •Public figures from Meetup, Discord, and Reddit calibrate scale; every uncited number here is an explicit assumption.
  • •Four planes: catalog, engagement, discovery, and trust — each with its own consistency and failure behavior.
  • •Power-law group sizes drive fanout, indexing, counters, and moderation design more than total user count.
Lead With the Long Tail
State in the first two minutes that the system must serve 1.8M micro-communities, not a few large audiences. That single sentence reframes fanout, search, and moderation and distinguishes this answer from a generic social-network design.
Do Not Design One Big News Feed
Treating the aggregator as a single global feed ignores that 90% of groups are too small for feed-driven growth; their members arrive through search and recommendations first.

Section Rescue Kit

Buzzwords to use:

Long-Tail DistributionCanonical Entity

Safe statements:

  • "I will separate catalog correctness from engagement latency, because they fail differently."
  • "Before choosing stores, let me define which plane owns each dataset and what staleness each can tolerate."
Design a Hobby Group Aggregator - System Design | WinJob | WinJob