0. 문제 정의

• 월간 읽기 count 어뷰징 가능
• PATCH 반복 호출로 조작 가능
• 정상 사용자 경험은 유지해야 함

1. 최종 결정 요약- Token Bucket 방식 사용

• member_id 기준 DB row 1개 유지
• burst 허용량: 3
• refill: 50~60초당 1개
• DB 원자적 UPDATE 기반으로 동시성 처리
• MySQL 기반으로 운영

2. Rate Limit 알고리즘 선택 - 왜 Token Bucket을 선택했는가

Fixed Window

고정된 구간으로 나누고, 각 구간 안에서 요청 수를 카운트하는 방식이다.

예를 들어 2분에 3회 제한이라면 00:00~02:00, 02:00~04:00처럼 고정된 윈도우를 만들고, 해당 구간의 요청 수가 3회를 넘으면 차단한다.

장점

구현이 가장 단순하다. 회원별로 현재 윈도우 시작 시각과 요청 count만 저장하면 되므로, DB 테이블 구조도 간단하다. 또한 INSERT ... ON DUPLICATE KEY UPDATE 방식으로 구현하면 요청 count 증가를 원자적으로 처리할 수 있어 동시성 처리도 비교적 쉽다.

단점

고정된 윈도우 경계에서 burst 문제가 발생한다. 예를 들어 2분에 3회 제한이 있을 때, 사용자가 01:58, 01:59, 02:00 직전에 3번 요청하고, 윈도우가 초기화된 직후 다시 3번 요청하면 짧은 시간 안에 총 6번의 요청이 통과할 수 있다. 즉, 이론적으로 설정한 limit의 최대 2배에 가까운 요청이 윈도우 경계에서 허용될 수 있다.