Katkat
Back

Design a Neighborhood Newsfeed System

NextdoorSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design a privacy-aware, hyperlocal social feed that serves real-time updates and emergency alerts based on strict neighborhood boundaries.

Scenario

Design the backend architecture for a hyperlocal neighborhood platform (similar to Nextdoor). The platform allows verified residents to publish updates, ask for recommendations, and post critical safety alerts. Content visibility is strictly restricted to members of a user's verified neighborhood and optionally its adjacent neighborhoods.

Requirements

Functional Requirements

  • Post Creation: Users can publish posts containing text, an optional image, and a category (e.g., General, Classifieds, Safety Alert).
  • Feed Retrieval: Users can view a paginated feed containing posts from their primary neighborhood and immediate adjacent neighborhoods.
  • Urgent Alerts: High-priority safety alerts must bypass standard feed delay and push to affected residents within 5 seconds.
  • Access Control & Privacy: Users can only view or interact with content belonging to their verified neighborhood clusters. Unverified or distant users must be blocked from reading private feeds.

Non-Functional Requirements

  • Low Latency: Feed retrieval p95 latency under 200 ms.
  • High Availability: 99.99% uptime, especially for consuming safety-critical information.
  • Consistency: Eventual consistency is acceptable for standard posts, but urgent alerts require immediate persistence and fanout.

Scale & Numbers

  • 50 million Daily Active Users (DAU).
  • 500,000 distinct neighborhood units globally (average 500–2,000 residents per neighborhood).
  • Each neighborhood has an average of 6 adjacent neighborhoods configured.
  • 10 million new posts created per day (~120 writes/second average, 500 peak).
  • 200 million feed fetch requests per day (~2,300 reads/second average, 10,000 peak).

What to Cover

  1. API Design: Core endpoints for publishing posts and retrieving the localized feed.
  2. Data Storage & Modeling: Schemas for posts, neighborhood geospatial boundaries/adjacency lists, and user membership.
  3. Feed Generation Architecture: Fan-out on write vs. fan-out on read trade-offs given the neighborhood graph topology.
  4. Geospatial & Boundary Partitioning: How to map locations and query adjacency efficiently.
  5. Reliability & Edge Cases: Handling hot neighborhoods during emergency events and preventing cross-boundary data leaks.

Hints

Hint 1

Unlike open social networks with arbitrary follower graphs, neighborhoods form discrete geographical nodes with static or semi-static adjacency graphs.

Hint 2

Evaluate a hybrid fan-out approach: fan-out on read (pull) for regular posts across adjacent neighborhoods, versus push fan-out for high-priority safety notifications.

Hint 3

Consider spatial indexing systems (such as S2 geometry or H3 hexagonal grids) or a relational adjacency graph to precompute neighborhood neighborhoods.

Follow-up questions

  • How does your architecture handle an emergency event where thousands of residents in one neighborhood refresh their feed simultaneously?
  • If neighborhood boundaries are split or merged by community moderators, how do you handle cache invalidation and historical post access?
  • How would you incorporate localized feed ranking (e.g., blending recency, proximity, and engagement) without blowing past the 200 ms latency budget?