Πώς χειρίζεστε 5 εκατομμύρια ψήφους σε 10 λεπτά σε κλίμακα;

Question

IT Interview Practice · Accepted Answer

Μην γράφετε κάθε ψήφο κατευθείαν σε μια row βάσης — **κάντε buffer τα writes, shard τους counters, και αποδεχτείτε eventual tally**. 5 εκατομμύρια ψήφοι σε 10 λεπτά είναι ~8.300 ψήφοι/sec κατά μέσο όρο, με spikes πολύ υψηλότερα (μια live τηλεοπτική στιγμή μπορεί να το 10πλασιάσει). Το κόλπο είναι να μετατρέψετε ένα hot single-row update σε πολλά ανεξάρτητα, παράλληλα increments.

```text
Client ─▶ Edge/API ─▶ Kafka (vote events) ─▶ Consumers ─┬─▶ Dedup store (SET one-vote)
                        (durable buffer)                 └─▶ Sharded counters (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodic sum of shards ──────────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live tally to clients
```

## Γιατί να κάνετε buffer τα writes

Μια ουρά όπως το **Kafka** αποσυζευγνύει το ingestion από το tallying. Το write του client είναι ένα φθηνό append· αν οι consumers μείνουν πίσω κατά τη διάρκεια ενός spike, τα events περιμένουν στο log αντί να κατακλύζουν τη βάση. Το Kafka δίνει επίσης **replay** — αν ένας consumer κάνει crash, ξανα-επεξεργάζεστε από το τελευταίο committed offset χωρίς να χάσετε ψήφους.

## Οι sharded counters σκοτώνουν το hotspot

Αν κάθε ψήφος για το "Option A" κάνει `UPDATE counter SET n=n+1 WHERE id='A'`, αυτή η μία row γίνεται bottleneck lock-contention — χιλιάδες transactions σειριοποιούνται σε μία row. Αντ' αυτού, σπάστε κάθε option σε **N shard rows** (`A:0 … A:63`). Κάθε increment χτυπάει ένα τυχαίο shard, οπότε τα writes απλώνονται σε N rows και τρέχουν παράλληλα. Το εμφανιζόμενο σύνολο είναι `SUM(shards)`, υπολογισμένο κάθε δευτερόλεπτο ή δύο από έναν aggregator. Στο Redis αυτό είναι απλώς N `INCR` keys· στο DynamoDB, N partition keys.

## Dedup μιας ψήφου

Επιβάλετε "μία ψήφος ανά χρήστη" με ένα idempotency key: `SADD voted:{pollId} {userId}` (ή ένα conditional put). Αν ο χρήστης υπάρχει ήδη, απορρίψτε το event πριν το increment. Κάντε το στον consumer, όχι στον client — οι clients λένε ψέματα και κάνουν retry.

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

Ο συνεντευκτής διερευνά αν αναγνωρίζετε το **πρόβλημα του μοναδικού hot-key** και καταφεύγετε σε buffering + sharding αντί για "πρόσθεσε περισσότερα DB replicas" (τα replicas κάνουν scale reads, όχι αυτό το write). Καλό: "χρησιμοποίησε ουρά και cache." Εξαιρετικό: κατονομάζετε το **eventual-consistency trade-off** — ο live αριθμός υστερεί από την πραγματικότητα κατά ένα δευτερόλεπτο — και υποστηρίζετε ότι αυτό είναι εντάξει για ένα vote count αλλά *όχι* για το τελικό πιστοποιημένο αποτέλεσμα, το οποίο ξανα-υπολογίζετε αυθεντικά μετά το κλείσιμο της ψηφοφορίας.

**Συνηθισμένη παγίδα:** χρήση ενός database transaction ανά ψήφο για "ακρίβεια". Σε αυτή την κλίμακα αυτό είναι που λιώνει.

## Trade-offs & τρόποι αποτυχίας

- **Eventual tally:** τα shard sums υστερούν· αποδεκτό για έναν live counter, κάντε reconcile στο κλείσιμο.
- **At-least-once delivery:** το Kafka μπορεί να ξανα-παραδώσει — το dedup κάνει τα increments idempotent, αλλιώς μετράτε διπλά.
- **Hot shard skew:** πολύ λίγα shards και εξακολουθείτε να έχετε contention· πολλά και το άθροισμα γίνεται ακριβό. 32–128 shards είναι τυπικό.
- **Δικαιοσύνη/απάτη:** rate-limit ανά IP/device· το one-vote SET είναι το όριο ακεραιότητάς σας. Αν το χάσετε σημαίνει ballot stuffing, όχι crash — αναμφισβήτητα χειρότερο.

Γιατί να κάνετε buffer τα writes

Οι sharded counters σκοτώνουν το hotspot

Dedup μιας ψήφου

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

Trade-offs & τρόποι αποτυχίας

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