Design a sports betting slip sharing feed

Problem Statement

Design a social feed platform where sports bettors share their betting slips (teams, odds, stakes), follow other users, and interact through likes and comments. Think of it as a sports-focused social network where the core content object is a bet slip tied to live sporting events and outcomes. The feed blends posts from followed users with trending and live-event-related content.

The key engineering challenges are building a low-latency personalized feed that handles spiky traffic (major games drive sudden surges), delivering near-real-time updates for likes, comments, and new posts, managing hot-key contention when viral slips accumulate rapid engagement, and scaling the social graph and notification fanout. Your design must handle millions of active users during peak sports seasons, with individual events driving tens of thousands of concurrent interactions on popular slips.

Key Requirements

Functional

• Slip sharing -- users can post a bet slip with event details (teams, odds, stake amount) and control visibility (public or followers-only)
• Personalized feed -- users see a home feed blending posts from followed accounts, live-event-related slips, and trending content with smooth cursor-based pagination
• Social interactions -- users can like and comment on slips with engagement counts updating in near real time
• Follow and notifications -- users can follow/unfollow others and receive notifications when followed users post new slips or when their own slips receive engagement

Non-Functional

• Scalability -- support 10 million daily active users with 100,000+ concurrent during major events; handle 50,000+ feed reads per second at peak
• Reliability -- no lost posts or dropped interactions; 99.9% feed availability even during traffic surges
• Latency -- feed loads within 200ms; new posts from followed users appear within 2 seconds; like and comment counts update within 1 second
• Consistency -- eventual consistency for feed materialization and engagement counters; strong consistency for follow graph mutations and post creation

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Feed Construction and Fanout Strategy

The home feed must blend content from multiple sources with low latency. Interviewers want to see how you balance precomputation with on-demand assembly and handle the fanout implications of popular accounts.

Hints to consider:

• Use fanout-on-write for normal users: when a user posts a slip, push the post ID into each follower's timeline cache (a Redis sorted set scored by timestamp)
• For users with very large follower counts, defer fanout or use fanout-on-read to avoid massive write amplification
• Blend precomputed followed-user content with live-event trending slips at read time using a lightweight merge step
• Support cursor-based pagination by returning the last post's score as the cursor; the client sends it back to fetch the next page

2. Hot-Key Contention on Viral Slips

When a popular bettor's slip goes viral during a championship game, thousands of likes and comments hit a single entity simultaneously. Naive designs cause lock contention and throughput collapse.

Hints to consider:

• Use sharded counters for engagement metrics: split a single like counter into N shards (e.g., 10 Redis keys), increment a random shard on each like, and sum all shards for the display value
• Batch counter updates: accumulate likes in a buffer and flush to the database periodically rather than on every individual interaction
• Use Kafka to decouple the engagement write path from counter updates; consumers process events in batches
• Apply backpressure and rate limiting on comments to prevent system overload during viral moments

3. Real-Time Update Delivery

Users expect to see new posts, likes, and comments appear without refreshing. Interviewers evaluate your push architecture for delivering updates efficiently.

Hints to consider:

• Maintain WebSocket connections from active clients to a gateway tier; route real-time updates through a Redis Pub/Sub layer keyed by user ID
• For feed updates, push lightweight notifications (new post available) rather than full post content; the client fetches details via the API
• For engagement count updates on slips the user is currently viewing, push delta updates through a channel keyed by slip ID
• Handle connection loss gracefully: on reconnection, the client provides its last-seen cursor and catches up via the standard feed API

4. Event-Driven Architecture and Idempotency

Posts, likes, comments, and notifications flow through an event pipeline. Retries and duplicate events are inevitable in distributed systems, and interviewers want to see how you prevent corruption.

Hints to consider:

• Assign unique event IDs to every action (post creation, like, comment) and deduplicate at each consumer using a Redis-based dedup cache with TTL
• Publish events to Kafka partitioned by slip ID for engagement events and by user ID for feed fanout events
• Make all event consumers idempotent: inserting a like with the same event ID is a no-op; counter updates use exactly-once semantics or compensating logic
• Use dead letter queues for events that fail processing after max retries, with alerting and manual inspection

5. Notification Fanout and Delivery

When a user with 100,000 followers posts a new slip, notifications must reach interested followers across push, in-app, and potentially email channels without overwhelming the system.

Hints to consider:

• Use a notification worker pool that consumes follow-graph events from Kafka, looks up each follower's notification preferences, and routes to the appropriate channel
• Throttle notification delivery using a job queue with rate limiting to spread the load over several seconds
• Batch in-app notifications for inactive users; prioritize push notifications for recently active followers
• Track notification delivery status (sent, delivered, opened) for analytics and debugging

Suggested Approach

Step 1: Clarify Requirements

Ask about user scale, peak concurrent users during major events, and the ratio of content producers to consumers. Clarify whether the feed should show real-time bet outcomes (odds changes, win/loss status) or just static slip data. Determine if trending/discovery features are in scope beyond the followed-user feed. Confirm notification channel requirements (push, in-app, email). Ask about content moderation needs for betting-related content.

Step 2: High-Level Architecture

Sketch the core services: Post Service (stores slips in PostgreSQL), Feed Service (assembles timelines from Redis caches), Social Graph Service (manages follow relationships), Engagement Service (processes likes and comments), Notification Service (delivers alerts across channels), and a Trending Service (computes popular slips based on recent engagement). Show Kafka as the event backbone connecting post creation to fanout workers, engagement events to counter updaters, and follow events to notification delivery. Place Redis in front of timelines, engagement counters, and connection routing. Include WebSocket gateways for real-time push.

Step 3: Deep Dive on Feed Assembly

Walk through a feed load request. The Feed Service checks the user's timeline cache in Redis (sorted set of slip IDs with timestamp scores). If the cache is warm, it reads the top N entries after the client's cursor, hydrates them by fetching full slip content and author metadata from cache or database, and returns the page with a new cursor. For cold caches (new user or expired), the service queries the follow graph, fetches recent posts from each followed user's outbox, merges and scores them, and populates the cache. Trending slips from the Trending Service are blended in at defined positions. The entire flow targets sub-200ms latency by keeping hot data in Redis and parallelizing hydration calls.

Step 4: Address Secondary Concerns

Cover engagement handling: likes and comments published to Kafka, consumed by the Engagement Service which updates sharded counters in Redis and persists to PostgreSQL in batches. Discuss real-time updates: WebSocket gateways subscribe to Redis Pub/Sub channels for user-specific feed updates and slip-specific engagement deltas. Address notifications: a worker pool consumes follow-graph events, respects user preferences and quiet hours, and routes through push, in-app, or email channels with rate limiting. Touch on monitoring: track feed latency, fanout lag, engagement processing throughput, notification delivery rates, and Kafka consumer lag. Discuss scaling: shard Redis by user ID, partition Kafka by slip ID for engagement and user ID for fanout, and auto-scale WebSocket gateways based on connection count.

Related Learning

Deepen your understanding of the patterns used in this problem:

• Ad Click Aggregator -- high-throughput event ingestion and real-time aggregation for engagement counting
• Distributed Counters -- sharded counter techniques for managing viral content engagement without hot-key contention
• Caching -- Redis sorted sets for precomputed timelines and low-latency engagement counters
• Message Queues -- Kafka for fanout pipelines, engagement processing, and notification delivery
• Databases -- storage strategies for social graphs, post content, and engagement data
• CDN -- serving static slip images and user avatars from edge locations