Interview Prep: System Design Rounds

Designing Real Systems/Assessment

Practice & Assessment

Test your understanding of Designing Real Systems

Multiple Choice Questions

In a URL shortener, why use HTTP 302 (temporary redirect) instead of HTTP 301 (permanent redirect) if you need to track click analytics?

The token bucket rate limiting algorithm allows burst traffic. What does this mean?

In a social feed system, when does fanout on write perform better than fanout on read?

In Kafka, if you have 3 consumers in a consumer group reading from a topic with 3 partitions, what happens when a 4th consumer joins the group?

Why does the hybrid fanout approach use fanout-on-read for celebrity accounts?

What does 'at-least-once delivery' mean in a message queue context, and what must consumers implement to handle it safely?

Coding Challenges

Token Bucket Rate Limiter

Implement a token bucket rate limiter class that supports multiple users. Constructor takes: rate (tokens added per second), burst (max bucket size). Method allow(userId) returns true if request is allowed and false if rate limited. Use current timestamp (not mocked) to calculate token refill. Tokens accumulate while user is idle (up to burst limit). Test scenario: rate=2, burst=5. User makes 5 requests instantly (all allowed, bucket drains). 6th request immediately after is rejected. Wait 1 second, then 2 more requests are allowed. No external dependencies. Implement without sleep() or timers — pass timestamp as parameter for testability: allow(userId, timestamp). Estimated time: 20 minutes.

Medium

Mini Project

Simplified URL Shortener Service

Build a working URL shortener as a Node.js or Python HTTP server. Must implement: POST /shorten with JSON body {url, customAlias?, ttlDays?} — returns {shortUrl, expiresAt}; GET /:shortId — returns 302 redirect to original URL or 410 Gone if expired; GET /stats/:shortId — returns {shortId, longUrl, clicks, createdAt, expiresAt}. ID generation must use base62 encoding of an auto-incrementing counter (not random UUIDs). Store data in SQLite. Implement an in-memory cache for the redirect path (GET /:shortId must use cache first). Track click count atomically. Add a cleanup job that runs on startup and removes expired URLs. Include a README explaining the architectural decisions made, referencing at least: caching strategy used, why 302 vs 301, and ID generation approach.

Medium