System Design Basics for Backend Developers · 강의

속도 제한과 스로틀링

토큰 버킷과 슬라이딩 윈도 알고리즘을 포함해 속도 제한이 시스템을 악용과 과부하로부터 보호하는 방법을 학습해 보세요.

레슨 4/413개 단계

속도 제한과 스로틀링은(는) CoddyKit의 무료 System Design Basics for Backend Developers 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 System Design Basics for Backend Developers 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. System Design Basics for Backend Developers 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why Rate Limit?

Rate limiting caps how many requests a client can make in a time window. It protects a system from abuse, accidental floods, and runaway clients.

Stops brute-force and scraping attacks
Ensures fair sharing among clients
Protects backends from overload

Rate Limiting vs Throttling

The terms overlap but differ slightly: rate limiting rejects requests over a hard cap, while throttling often slows or queues excess requests rather than rejecting them outright.

Fixed Window Counter

The simplest scheme counts requests in fixed time windows, e.g. 100 per minute. It is easy but has an edge problem: a client can send 100 at the end of one window and 100 at the start of the next — 200 in a few seconds.

limit = 100
window = '12:00:00-12:00:59'
count = 0
# reset count to 0 each new window

Sliding Window

A sliding window smooths the edge problem by weighting the previous window or tracking timestamps over a rolling interval. It gives a more accurate, fairer limit at the cost of more bookkeeping.

Token Bucket

The token bucket is the most popular algorithm. Tokens refill at a steady rate up to a capacity. Each request consumes a token; if the bucket is empty, the request is rejected. This allows short bursts while bounding the average rate.

import time
class Bucket:
    def __init__(self, cap, rate):
        self.cap = cap
        self.rate = rate
        self.tokens = cap
        self.last = time.time()
    def allow(self):
        now = time.time()
        self.tokens = min(self.cap, self.tokens + (now - self.last) * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

b = Bucket(5, 1)
print([b.allow() for _ in range(7)])

Leaky Bucket

The leaky bucket processes requests at a fixed rate, queuing bursts and 'leaking' them out steadily. It smooths traffic into a constant outflow — good when the downstream needs a steady, predictable load.

Choosing the Limit Key

Decide what to limit on:

Per API key or user — fair per-account limits
Per IP — defends against anonymous abuse
Per endpoint — protects expensive operations

Often you combine several keys.

Communicating Limits

Tell clients their status with standard headers and the right status code, so well-behaved clients can back off.

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1735689600

Distributed Rate Limiting

With many app servers, an in-memory counter per server is inconsistent. Use a shared store like Redis with atomic increments (or Lua scripts) so the limit is enforced globally across the fleet.

INCR rl:user:42
EXPIRE rl:user:42 60
# reject when value > limit

Rate Limiting and DDoS

Rate limiting complements DDoS protection. Application-layer limits stop a single abusive client, while edge and network defenses absorb large volumetric floods before they reach your servers. Defense in depth uses both.

Designing Good Limits

Set limits from real usage data, allow reasonable bursts, expose clear headers, and return 429 with Retry-After. Consider tiered limits — higher caps for paid plans, stricter ones for unauthenticated traffic.

Quick Check

Test your understanding of rate limiting.

인터랙티브 레슨에서 답해보세요

Recap

You learned to protect systems with rate limiting:

Fixed window, sliding window, token bucket, and leaky bucket
Choose limit keys: per user, per IP, per endpoint
Return 429 with Retry-After and rate-limit headers
Use a shared store like Redis for distributed enforcement

무료로 시작

AI 튜터와 함께 System Design Basics for Backend Developers을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스: 12
레슨: 48

무료로 학습 시작 전체 코스 보기

자주 묻는 질문

“속도 제한과 스로틀링” 강의는 무료인가요?

네 — “속도 제한과 스로틀링” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 System Design Basics for Backend Developers 강의 전체를 잠금 해제할 수 있습니다. System Design Basics for Backend Developers 강의에는 총 4개의 강의가 포함되어 있습니다.

“속도 제한과 스로틀링”에서 뭘 배우나요?

토큰 버킷과 슬라이딩 윈도 알고리즘을 포함해 속도 제한이 시스템을 악용과 과부하로부터 보호하는 방법을 학습해 보세요. 브라우저에서 직접 실행하는 실습 코드로 System Design Basics for Backend Developers을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

System Design Basics for Backend Developers을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 System Design Basics for Backend Developers은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“속도 제한과 스로틀링” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 System Design Basics for Backend Developers 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 System Design Basics for Backend Developers 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← System Design Basics for Backend Developers(으)로 돌아가기