Πώς χτίζετε έναν real-time counter προβολών/likes για viral posts;

Question

IT Interview Practice · Accepted Answer

Μην κάνετε ποτέ `UPDATE posts SET views = views + 1` ανά event σε ένα hot post — αυτή η μία row γίνεται lock bottleneck. **Κάντε increment στο Redis, με batch-flush στη βάση** κάθε λίγα δευτερόλεπτα, και διαβάστε το count από το Redis. Η βάση αποθηκεύει durable σύνολα, όχι live 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** απορροφά την καταιγίδα των writes. Ένα μοναδικό `INCR views:{post}` είναι atomic και χειρίζεται 100k+ ops/s σε ένα key — τάξεις μεγέθους πέρα από μια Postgres row. Αυτός ο counter είναι η πηγή αλήθειας για τα *reads*, οπότε οι θεατές βλέπουν τον αριθμό να κινείται ακαριαία.
- **Dedup για likes/μοναδικές προβολές**: ένας ωμός counter μετράει διπλά τα refreshes. Χρησιμοποιήστε `SADD seen:{post} {userId}` και κάντε `INCR` μόνο όταν η προσθήκη είναι νέα· για φθηνά approximate uniques σε τεράστια κλίμακα χρησιμοποιήστε **HyperLogLog** (`PFADD`/`PFCOUNT`) — λίγα KB εκτιμούν εκατομμύρια uniques με σφάλμα ~2%.
- **Ο batched flusher** αδειάζει περιοδικά το delta στη βάση: `UPDATE posts SET views = views + delta`. Το flush κάθε 5s ή κάθε N increments μετατρέπει ένα εκατομμύριο writes σε μια χούφτα — η βάση κρατά το durable σύνολο για cold posts και analytics.
- **Το read path** σερβίρει από το Redis· σε ένα cache miss διαβάζει το σύνολο της βάσης και ξανα-ζεσταίνει το Redis. Τα likes χρειάζονται per-user state (το έκανα *εγώ* like), οπότε αποθηκεύστε το set, όχι απλώς έναν αριθμό.

## Οπτική συνέντευξης

Οι συνεντευκτές ελέγχουν αν αποδέχεστε **eventual consistency για τα counts**. Το "καλό" είναι "cache το count"· το "εξαιρετικό" είναι το buffering των *writes* — αναγνωρίζοντας ότι το bottleneck είναι η write contention σε μια hot row, όχι το read load. Διερευνούν το trade: είναι αποδεκτό ένα approximate count; Για τα view counts, ναι — κανείς δεν παρατηρεί 1.203.428 vs 1.203.450. Η παγίδα είναι να ανησυχείτε για ακριβή counts και να καταφεύγετε σε transaction, ξαναφέρνοντας το lock που αποφεύγατε.

## Trade-offs και αποτυχία

- **Ακρίβεια vs throughput**: τα ακριβή counts χρειάζονται dedup sets (βαριά σε μνήμη)· το approximate HyperLogLog είναι μικροσκοπικό και γρήγορο. Επιλέξτε ανά feature — τα likes είναι ακριβή, τα view counts μπορούν να είναι approximate.
- **Durability**: το Redis είναι in-memory. Αν πεθάνει πριν ένα flush, χάνετε το μη-flushed delta. Ενεργοποιήστε το AOF και κρατήστε τα flush windows σύντομα (δευτερόλεπτα) για να περιορίσετε την απώλεια· το σύνολο της βάσης συν ένα μικρό κενό είναι αποδεκτό για έναν view counter.
- **Hot key**: ένα viral post συγκεντρώνει όλο το traffic σε ένα Redis key. Κάντε το shard σε `views:{post}:{0..9}` και αθροίστε στο read, ή δρομολογήστε hot keys σε ένα dedicated node ώστε ένα post να μην μπορεί να κορεσίσει το shard.

Αρχιτεκτονική

Στοιχεία και ροή

Οπτική συνέντευξης

Trade-offs και αποτυχία

Σχετικές ερωτήσεις