Practice/Amazon/Design Twitter

Design Twitter

System DesignMust

Problem Statement

Design a social media platform similar to Twitter but incorporating e-commerce functionality where people post short updates, follow others, consume a personalized feed, and can discover and purchase products directly within the platform. The system blends a real-time social feed with reliable commerce operations including inventory management and payment processing.

Interviewers ask this to see if you can merge two demanding domains: a low-latency social feed (read-heavy, fanout tradeoffs, real-time updates) with reliable e-commerce (multi-step workflows, inventory, payments, idempotency). They are testing whether you can define clear boundaries between social and commerce domains, scale hot paths, and keep transactional integrity while maintaining a crisp user experience.

Key Requirements

Functional

• Content creation -- users post short updates with optional media and product attachments or tags
• Personalized feed -- users follow accounts and see a personalized, real-time home timeline that mixes followed content with recommended products
• Product discovery -- users search and discover tweets and products, view product details in-app, and add items to a shopping cart
• Checkout -- users complete checkout securely including payment, inventory reservation, order confirmation, and delivery status notifications

Non-Functional

• Scalability -- support hundreds of millions of users with highly skewed follower distributions (celebrities with millions of followers)
• Reliability -- maintain 99.9% uptime for feed delivery; zero lost transactions or double charges for commerce operations
• Latency -- feed loading under 200ms p95, product page loads under 200ms, bid acceptance under 500ms
• Consistency -- eventual consistency for engagement metrics and follower counts; strong consistency for inventory and payment operations

What Interviewers Focus On

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

1. Feed Generation and Fanout Strategy

The core challenge is delivering a personalized, low-latency feed that blends social content with product recommendations. Celebrity users with millions of followers create massive write amplification with naive fanout approaches.

Hints to consider:

• Use a hybrid fanout model: fanout-on-write for normal users (pre-materialize timelines), fanout-on-read for high-follower accounts (merge at read time)
• Cache per-user timeline heads in Redis or a similar low-latency store, with pagination tokens for efficient infinite scroll
• Blend organic content with product recommendations at serve time using lightweight ranking rather than heavy ML inference
• Handle timeline cache invalidation when users follow/unfollow accounts or when posts are deleted

2. Domain Separation Between Social and Commerce

Tightly coupling social data and product catalog into one schema leads to poor query performance and brittle evolution. Each domain has fundamentally different access patterns and consistency requirements.

Hints to consider:

• Separate the social graph, content store, and product catalog into independent services with clear API boundaries
• Use event-driven integration (Kafka) to synchronize data across domains without tight coupling
• Design the product attachment on tweets as a lightweight reference (product ID) that the client resolves from the product service
• Allow independent scaling of the feed path (read-heavy, eventual consistency) and the commerce path (write-heavy, strong consistency)

3. E-commerce Checkout Workflow

The purchase flow spans inventory reservation, payment authorization, order creation, and fulfillment notification, each of which can fail independently.

Hints to consider:

• Implement a saga pattern where each step emits events on success and failure, with compensating transactions for rollback
• Use idempotency keys on all payment gateway calls and database writes to safely retry without duplicate charges or orders
• Design short-lived inventory holds (5-10 minutes) with TTL-based auto-release when carts are abandoned
• Persist workflow state durably so interrupted processes can be resumed after crashes

4. Real-Time Updates and Notifications

Feed updates, engagement metrics, order status changes, and push notifications all require low-latency delivery to connected clients.

Hints to consider:

• Use WebSocket connections for real-time feed updates and order status changes, with fallback to polling for disconnected clients
• Implement a pub-sub layer (Redis pub/sub or Kafka) to fan out events to WebSocket gateway servers
• Batch engagement counter updates to reduce write amplification while maintaining near-real-time freshness
• Use separate notification channels for social events (likes, follows) and commerce events (order shipped, delivery update)

Suggested Approach

Step 1: Clarify Requirements

Confirm scope and priorities with the interviewer. Ask about the expected ratio of social to commerce engagement, whether product listings are first-party or third-party marketplace, if live shopping (stream + buy) is in scope, and target geographic distribution. Clarify whether you need to handle returns and refunds or just order creation. Establish whether the recommendation engine is in scope or treated as a black box.