Bytedance·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

May 2026

Summary

Bytedance system design round, one big question the whole time. The problem was a like-counting system for a social platform and it went pretty deep into stream processing and approximation tradeoffs. Felt okay about it but there were definitely moments where I was just talking to fill silence.

Questions Asked (1)

Design a like-counting system for a social platform. You need to support: (1) given a post ID, return the like count over the last minute; (2) globally, return the post with the most likes in the last minute; (3) return the top-liked post per region over the last minute.

System DesignTechnical Trade-offsData Modeling

Author's notes

The question sounds straightforward until you realize Q1 and Q2/Q3 have fundamentally different consistency requirements and you probably shouldn't serve them from the same pipeline.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a streaming aggregation pipeline using a time-series store or in-memory counters with sliding windows. Propose a two-tier architecture: per-post counters for point queries and a global/regional leaderboard using a sorted set or heap, with periodic rollups to handle the last-minute window. Discuss trade-offs between accuracy, latency, and cost, and how to handle late data and hot posts.

Pro tip: Emphasize that the 'last minute' is a sliding window, not a fixed tumbling window, and propose approximate algorithms (e.g., count-min sketch or sampled counters) for scalability while maintaining acceptable accuracy. Also, mention the need for idempotent like events to avoid double-counting.

1. Clarify Requirements and Scale

Ask about expected QPS, number of posts, regions, and accuracy requirements. Determine if exact counts are needed or if approximations are acceptable, and whether the system must handle late-arriving events.

2. Design Data Ingestion and Storage

Propose a stream processing pipeline (e.g., Kafka + Flink) to ingest like events. Store per-post counts in a time-series database or in-memory store with sliding window support, and maintain global/regional aggregates.

3. Implement Query APIs

For per-post count, query the time-series store or compute from a sliding window counter. For global/regional top posts, use a sorted set (e.g., Redis ZSET) or a heap that is updated as counts change, with periodic refresh.

4. Handle Scale and Trade-offs

Discuss sharding by post ID or region, using approximate counting for hot posts, and caching. Address trade-offs between exactness, latency, and resource usage, and propose a hybrid approach.

5. Address Edge Cases and Reliability

Cover late data handling (watermarks), idempotency, failure recovery, and consistency across regions. Mention monitoring and alerting for anomalies.

Key Points to Mention

Sliding window vs. tumbling window and how to implement with timestamps
Use of stream processing frameworks (Kafka, Flink) for real-time aggregation
Data stores: Redis sorted sets for leaderboards, time-series DBs for per-post counts
Approximate algorithms (count-min sketch, HyperLogLog) for scalability
Sharding and partitioning strategies for posts and regions
Handling late events and idempotency to ensure accurate counts

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.