바이럴 게시물을 위한 실시간 조회수/좋아요 카운터를 어떻게 만드시겠습니까?

Question

IT Interview Practice · Accepted Answer

hot 게시물에서 이벤트마다 `UPDATE posts SET views = views + 1`을 절대 실행하지 마십시오 — 그 하나의 row가 lock 병목이 됩니다. **Redis에서 증가시키고, 몇 초마다 DB로 batch-flush**하며, 카운트를 Redis에서 읽으십시오. DB는 실시간 트래픽이 아니라 내구성 있는 총계를 저장합니다.

## 아키텍처

```text
Client tap ─▶ API ─▶ Redis INCR views:{post}   (live, source of truth for reads)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 every ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (durable)
                          ▲
                 read path: GET Redis (fallback DB on miss)
```

## 구성 요소와 흐름

- **Redis INCR**이 write 폭풍을 흡수합니다. 단일 `INCR views:{post}`는 원자적이며 하나의 key에서 초당 10만 회 이상의 연산을 처리합니다 — Postgres row보다 수십 배 이상입니다. 이 카운터는 *읽기*의 진실 공급원이므로, 시청자는 숫자가 즉시 움직이는 것을 봅니다.
- **좋아요/고유 조회를 위한 dedup**: 원시(raw) 카운터는 새로고침을 중복 계산합니다. `SADD seen:{post} {userId}`를 사용해 추가가 새로운 경우에만 `INCR`하고, 대규모에서 저렴한 근사 고유값이 필요하면 **HyperLogLog**(`PFADD`/`PFCOUNT`)를 사용하십시오 — 몇 KB로 수백만 고유값을 약 2% 오차 내로 추정합니다.
- **Batch flusher**는 주기적으로 delta를 DB로 흘려보냅니다: `UPDATE posts SET views = views + delta`. 5초마다 또는 N번의 증가마다 flush하면 백만 건의 write가 몇 건으로 줄어듭니다 — DB는 cold 게시물과 분석용 내구성 총계를 보관합니다.
- **읽기 경로(Read path)**는 Redis에서 제공하며, cache miss 시 DB 총계를 읽고 Redis를 다시 warm합니다. 좋아요는 사용자별 상태(*내가* 좋아요했는가)가 필요하므로 숫자만이 아니라 set을 저장하십시오.

## 면접 관점

면접관은 당신이 **카운트에 대한 최종적 일관성(eventual consistency)**을 받아들이는지 시험합니다. "좋은" 답변은 "카운트를 캐시한다"이고, "훌륭한" 답변은 *write*를 버퍼링하는 것 — 병목이 read load가 아니라 hot row에 대한 write 경합임을 인식하는 것입니다. 그들은 트레이드오프를 파고듭니다: 근사 카운트가 허용되는가? 조회수의 경우 그렇습니다 — 아무도 1,203,428과 1,203,450을 구분하지 못합니다. 함정은 정확한 카운트를 걱정하며 트랜잭션에 손을 뻗어, 피하려던 lock을 다시 도입하는 것입니다.

## 트레이드오프와 실패

- **정확도 vs throughput**: 정확한 카운트는 dedup set(메모리 부담)이 필요하고, 근사 HyperLogLog는 작고 빠릅니다. 기능별로 선택하십시오 — 좋아요는 정확하게, 조회수는 근사로 가능합니다.
- **내구성(Durability)**: Redis는 인메모리입니다. flush 전에 죽으면 flush되지 않은 delta를 잃습니다. AOF를 활성화하고 flush 윈도우를 짧게(초 단위) 유지하여 손실을 제한하십시오. 조회 카운터에는 DB 총계 + 작은 간극이면 허용됩니다.
- **Hot key**: 바이럴 게시물은 모든 트래픽을 하나의 Redis key에 집중시킵니다. `views:{post}:{0..9}`로 분산하고 읽을 때 합산하거나, hot key를 전용 노드로 라우팅하여 한 게시물이 shard를 포화시키지 못하게 하십시오.

아키텍처

구성 요소와 흐름

면접 관점

트레이드오프와 실패

관련 질문