คุณจะสร้าง view/like counter แบบ real-time สำหรับโพสต์ที่เป็นไวรัลอย่างไร?

Question

IT Interview Practice · Accepted Answer

อย่าทำ `UPDATE posts SET views = views + 1` ต่อ event บนโพสต์ที่ร้อน — row เดียวนั้นจะกลายเป็น lock bottleneck **เพิ่มค่าใน Redis แล้ว batch-flush ลง DB** ทุกไม่กี่วินาที และอ่านค่า count จาก Redis DB เก็บยอดรวมที่ durable ไม่ใช่ traffic สด

## สถาปัตยกรรม

```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** ดูดซับพายุการเขียน `INCR views:{post}` ครั้งเดียวเป็น atomic และรองรับ 100k+ ops/s บน key เดียว — มากกว่า row ของ Postgres หลายเท่าตัว counter นี้คือ source of truth สำหรับ *การอ่าน* ดังนั้นผู้ชมจะเห็นตัวเลขขยับทันที
- **Dedup สำหรับ like/unique view**: counter ดิบจะนับ refresh ซ้ำสอง ใช้ `SADD seen:{post} {userId}` แล้ว `INCR` เฉพาะเมื่อการ add เป็นค่าใหม่ สำหรับ unique แบบประมาณราคาถูกที่ scale มหาศาลให้ใช้ **HyperLogLog** (`PFADD`/`PFCOUNT`) — ไม่กี่ KB ประมาณ unique หลักล้านได้ภายในความคลาดเคลื่อนราว 2%
- **Batched flusher** จะ drain delta ลง DB เป็นระยะ: `UPDATE posts SET views = views + delta` การ flush ทุก 5 วินาทีหรือทุก N increment เปลี่ยนการเขียนหนึ่งล้านครั้งให้เหลือเพียงไม่กี่ครั้ง — DB เก็บยอดรวมที่ durable สำหรับโพสต์ที่เย็นและงาน analytics
- **Read path** เสิร์ฟจาก Redis เมื่อ cache miss จะอ่านยอดรวมจาก DB แล้ว re-warm Redis Like ต้องมี state ต่อผู้ใช้ (ฉันกด like หรือยัง) ดังนั้นต้องเก็บ set ไม่ใช่แค่ตัวเลข

## มุมมองการสัมภาษณ์

ผู้สัมภาษณ์ทดสอบว่าคุณยอมรับ **eventual consistency สำหรับ count** หรือไม่ "ดี" คือ "cache ค่า count" "เยี่ยม" คือการ buffer *การเขียน* — ตระหนักว่า bottleneck คือ write contention บน row ที่ร้อน ไม่ใช่ read load พวกเขาจะจี้ถามข้อแลกเปลี่ยน: count แบบประมาณยอมรับได้ไหม? สำหรับ view count ได้ — ไม่มีใครสังเกตว่า 1,203,428 กับ 1,203,450 ต่างกัน กับดักคือกังวลเรื่อง count ที่แม่นยำแล้วไขว่คว้าหา transaction ซึ่งนำ lock ที่คุณพยายามหลีกเลี่ยงกลับมา

## ข้อแลกเปลี่ยนและ failure

- **ความแม่นยำ vs throughput**: count ที่แม่นยำต้องใช้ dedup set (กิน memory มาก) HyperLogLog แบบประมาณเล็กและเร็ว เลือกตามแต่ละฟีเจอร์ — like ต้องแม่นยำ view count ประมาณได้
- **Durability**: Redis อยู่ใน memory ถ้ามันตายก่อน flush คุณจะเสีย delta ที่ยังไม่ flush เปิด AOF และให้ช่วง flush สั้น (หลักวินาที) เพื่อจำกัดการสูญเสีย ยอดรวมใน DB บวกช่องว่างเล็ก ๆ ยอมรับได้สำหรับ view counter
- **Hot key**: โพสต์ที่เป็นไวรัลรวม traffic ทั้งหมดไว้ที่ Redis key เดียว แบ่ง (shard) เป็น `views:{post}:{0..9}` แล้ว sum ตอนอ่าน หรือ route hot key ไปยัง node เฉพาะเพื่อไม่ให้โพสต์เดียวทำให้ shard อิ่มตัว

สถาปัตยกรรม

องค์ประกอบและการไหลของงาน

มุมมองการสัมภาษณ์

ข้อแลกเปลี่ยนและ failure

คำถามที่เกี่ยวข้อง