Πώς στέλνετε promo codes σε 1 εκατομμύριο χρήστες σε ένα σύντομο χρονικό παράθυρο;

Question

IT Interview Practice · Accepted Answer

Μην κάνετε ποτέ loop πάνω σε 1 εκατομμύριο χρήστες μέσα σε έναν request handler — **κάντε fan out μέσα από μια ουρά (queue)**, κάντε throttle σε ό,τι μπορεί να δεχτεί ο κάθε provider, κάντε κάθε αποστολή **idempotent**, και δρομολογήστε τις αποτυχίες σε ένα DLQ για retry. Η κλήση του API απλώς κάνει enqueue· οι workers κάνουν το αργό I/O.

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

```text
Admin ─▶ Campaign API ─▶ [enqueue job] ─▶ Kafka/SQS ─┐
                                                     ▼
   ┌──────────────── Worker pool (autoscaled) ───────────────┐
   │  claim ─▶ dedup(Redis SETNX) ─▶ rate-limiter ─▶ provider │
   └──────────┬──────────────────────────────┬───────────────┘
              │ ok                            │ fail (5xx/timeout)
              ▼                               ▼
        sent_log (DB)                    Retry (backoff) ─▶ DLQ
```

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

- **Το Campaign API** γράφει την καμπάνια και κάνει enqueue τα jobs — ένα ανά χρήστη ή ανά **batch των ~500** για να μειώσει το overhead της ουράς. Επιστρέφει ακαριαία· οι αποστολές του 1 εκατομμυρίου γίνονται πίσω από την ουρά.
- **Η ουρά (Kafka / SQS)** είναι το buffer και το log για *replay*. Αν οι workers κάνουν crash, τα μηνύματα παραμένουν εκεί· κανένας κώδικας δεν χάνεται. Κάντε partition με βάση το `user_id` ώστε η σειρά ανά χρήστη να είναι σταθερή.
- **Το worker pool** τραβάει jobs και κάνει autoscale με βάση το queue lag. Κάθε worker: (1) δεσμεύει έναν μοναδικό promo code, (2) ελέγχει ένα **dedup key** `SETNX sent:{campaign}:{user}` στο Redis ώστε ένα ξανα-παραδοθέν μήνυμα να μη στείλει ποτέ διπλά, (3) περνάει μέσα από έναν **rate limiter** διαστασιολογημένο στο quota του provider, (4) καλεί Email/SMS/Push.
- **Ο rate limiter** είναι το κρίσιμο σημείο: το SendGrid ή το Twilio θα σας κάνει throttle ή blacklist πάνω από το όριό τους. Ένα Redis token bucket ανά provider βάζει πλαφόν στο outbound RPS ανεξάρτητα από το πόσοι workers τρέχουν.
- **Το DLQ** πιάνει τα poison messages μετά από N retries με exponential backoff + jitter, ώστε μια κακή διεύθυνση να μη μπλοκάρει ποτέ την καμπάνια.

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

Ο συνεντευκτής διερευνά αν καταλαβαίνετε το **decoupling και το back-pressure**. Μια "εξαιρετική" απάντηση κατονομάζει την ακριβή αποτυχία: χωρίς idempotency, μια at-least-once ουρά συν ένα retry ισοδυναμεί με χρήστες που παίρνουν τρεις κωδικούς· χωρίς rate limiter, κάνετε self-DDoS τον provider και σας κάνει throttle στο μηδέν. Η συνηθισμένη παγίδα είναι να κάνετε το fan-out σύγχρονα ("απλά `Promise.all`") — αυτό δεσμεύει connections, δεν έχει retry, και χάνει τα πάντα σε ένα deploy.

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

- **At-least-once vs exactly-once**: οι ουρές δίνουν at-least-once φθηνά· το "effectively once" το αγοράζετε με το Redis dedup key, όχι με έναν ακριβό exactly-once broker.
- **Throughput vs όρια provider**: μπορείτε να προσθέτετε workers επ' άπειρον, αλλά το quota του provider είναι το πραγματικό ταβάνι — ζητήστε αύξηση quota ή κάντε pre-warm πριν την καμπάνια.
- **Αποτυχία**: Redis down → οι αποστολές κολλάνε (fail closed, μην παρακάμπτετε το dedup ρισκάροντας διπλά). Κρατήστε έναν counter ανά καμπάνια ώστε να μπορείτε να κάνετε resume, όχι restart, μετά από ένα incident.

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

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

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

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

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