Design a global, high-throughput rate limiter that enforces per-user and per-API quotas across multiple regions with low latency and burst tolerance. Choose and justify an algorithm (e.g., token bucket vs. leaky bucket), outline the data model, partitioning and sharding strategy, clock/time-window semantics, consistency trade-offs, and handling of hot keys. Describe scaling strategies, capacity planning math (including how many machines are needed to handle a 2× traffic increase), failure modes, backpressure, observability, and APIs for configuration and metrics.

This question evaluates distributed systems design, scalability, consistency trade-offs, rate-limiting algorithms, data modeling, and operational competencies required to build a global, low-latency multi-region service.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Pinterest.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Pinterest during technical interviews.

Design a global high-throughput rate limiter | Pinterest Interview Question

System Design: Global, High-Throughput Rate Limiter

Context

You are designing a global, multi-region rate-limiting service that enforces quotas:

Per-user (across all APIs)
Per-API (across all users)
Per-user-per-API (composite)

The system must be low-latency, tolerate bursts, and operate across multiple regions.

Requirements

Design and justify:

Algorithm choice (e.g., token bucket vs. leaky bucket) with burst tolerance and latency considerations.
Data model for quotas, runtime state, and metrics.
Partitioning and sharding strategy for a global deployment.
Clock/time-window semantics (fixed vs. sliding windows, monotonic time handling).
Consistency trade-offs (global correctness vs. latency) and how you bound overages.
Hot-key handling strategies.
Scaling strategies and capacity planning math, including how many machines are required if traffic doubles (2×), with clear assumptions and formulas.
Failure modes and mitigations.
Backpressure behavior and client guidance.
Observability: metrics, tracing, dashboards, and alerts.
APIs for configuration and metrics.

Assume a mixed workload with both regional and global traffic patterns, and that some users may send traffic from multiple regions concurrently.

Requirements

Design and justify:

Algorithm choice (e.g., token bucket vs. leaky bucket) with burst tolerance and latency considerations.

Data model for quotas, runtime state, and metrics.

Partitioning and sharding strategy for a global deployment.

Clock/time-window semantics (fixed vs. sliding windows, monotonic time handling).

Consistency trade-offs (global correctness vs. latency) and how you bound overages.

Hot-key handling strategies.

Scaling strategies and capacity planning math, including how many machines are required if traffic doubles (2×), with clear assumptions and formulas.

Failure modes and mitigations.

Backpressure behavior and client guidance.

Observability: metrics, tracing, dashboards, and alerts.

APIs for configuration and metrics.

Assume a mixed workload with both regional and global traffic patterns, and that some users may send traffic from multiple regions concurrently.

Design a global high-throughput rate limiter

Quick Overview

System Design: Global, High-Throughput Rate Limiter

Context

Requirements

Solution

Comments (0)

Design a global high-throughput rate limiter

Quick Overview

System Design: Global, High-Throughput Rate Limiter

Context

Requirements

Solution

Comments (0)