Like/Unlike System

February 27, 2022 7:00 PM PST

---

This document summarizes a mock system design interview focused on creating a Like/Unlike feature for a marketplace platform. The interview covered functional and non-functional requirements, system architecture, database choices, and scalability considerations. The goal was to design a system that efficiently handles user interactions with items in the marketplace.

Requirements

Functional Requirements

• Users should be able to like or unlike an item.
• Users should be able to check if they have liked an item.
• Users should be able to see the total number of likes for an item.

Non-Functional Requirements

• Start with a small number of users.
• Accuracy of like counts is not a high priority.
• Feedback on like/unlike actions should be provided, but real-time accuracy is not critical.

System Design

External APIs

• like(user, itemId)
• unlike(user, itemId)
• getLikeTotalCount(itemId)
• isLikedBy(user, itemId)

Database Design

• Schema:
  • User, ItemID
  • ItemID, TotalLikes
• Database Choice: PostgreSQL is preferred due to its native support for change feeds, ease of management, and consistency.

Handling Likes and Unlikes

• When a user likes an item, a new row is created; when unliking, the row is either removed or marked with a flag.
• Trade-offs include the impact on the like/unlike and isLikedBy operations.

Scalability Considerations

• Expected load:
  • Like/Unlike: 100,000 QPS
  • GetLikeTotalCount: 1M QPS
  • IsLikedBy: 1M QPS
• Strong consistency is not required for total likes, but immediate feedback on user actions is necessary.

Sharding Strategy

• Shard by userID for user likes and by itemID for total likes.
• Considerations for sharding include the potential for uneven data distribution and the need for a fixed number of shards to start.

Load Balancing and Resilience

• Implement a load balancer to avoid single points of failure.
• Consider using a hash function to determine which shard to direct requests to.

Caching

• Caching can improve performance but introduces complexity in maintaining strong consistency.
• Local caching strategies may be employed to ensure quick access to frequently requested data.

Feedback and Challenges

• The candidate demonstrated good requirement clarification skills but showed some nervousness.
• Scalability and resiliency aspects were identified as areas for improvement.
• Emphasis on the need for a caching strategy and the importance of handling high QPS effectively.

Key Takeaways

• The design must prioritize read-heavy operations and consider the use of caching and sharding.
• Strong consistency is challenging but can be managed with local caches and message queues.
• The candidate should focus on breaking down large-scale questions into smaller, manageable parts during interviews.