როგორ აგზავნით promo კოდებს 1M მომხმარებელთან მოკლე ფანჯარაში?

Question

IT Interview Practice · Accepted Answer

არასდროს გაატაროთ 1M მომხმარებელი ციკლში request handler-ის შიგნით — **გაანაწილეთ (fan out) queue-ის მეშვეობით**, დააყენეთ throttle იმ დონეზე, რასაც თითოეული provider იღებს, გახადეთ ყოველი გაგზავნა **idempotent** და მიმართეთ ჩავარდნები DLQ-ში ხელახალი მცდელობისთვის. API გამოძახება მხოლოდ ამატებს queue-ში; ნელ I/O-ს worker-ები ასრულებენ.

## არქიტექტურა

```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** ჩაწერს კამპანიას და დაამატებს job-ებს queue-ში — თითო მომხმარებელზე ან **~500-იან batch-ზე**, რომ შემცირდეს queue-ის overhead. ის მყისვე ბრუნდება; 1M გაგზავნა queue-ის უკან ხდება.
- **Queue (Kafka / SQS)** არის buffer და *replay* ლოგი. თუ worker-ები ჩავარდნენ, შეტყობინებები ადგილზე რჩება; არცერთი კოდი არ იკარგება. დაყავით partition `user_id`-ით, რომ თითო მომხმარებელზე თანმიმდევრობა სტაბილური იყოს.
- **Worker pool** იღებს job-ებს და ავტომატურად მასშტაბირდება queue-ის lag-ის მიხედვით. თითოეული worker: (1) დაჯავშნის უნიკალურ promo კოდს, (2) შეამოწმებს **dedup გასაღებს** `SETNX sent:{campaign}:{user}` Redis-ში, რომ ხელახლა მიწოდებულმა შეტყობინებამ ვერასდროს გააგზავნოს ორმაგად, (3) გაატარებს **rate limiter**-ში, რომელიც provider-ის quota-ზეა მორგებული, (4) გამოიძახებს Email/SMS/Push-ს.
- **Rate limiter** არის ბირთვი: SendGrid ან Twilio დაგიდებთ throttle-ს ან blacklist-ს, თუ მათ ლიმიტს გადააჭარბებთ. Redis token bucket თითო provider-ზე ზღუდავს outbound RPS-ს, მიუხედავად იმისა, რამდენი worker მუშაობს.
- **DLQ** იჭერს "მოწამლულ" შეტყობინებებს N ხელახალი მცდელობის შემდეგ, ექსპონენციალური backoff + jitter-ით, ისე რომ ცუდმა მისამართმა ვერ დაბლოკოს კამპანია.

## ინტერვიუს პერსპექტივა

ინტერვიუერი ამოწმებს, გესმით თუ არა **decoupling და back-pressure**. "შესანიშნავი" პასუხი ასახელებს ზუსტ ჩავარდნას: idempotency-ის გარეშე, at-least-once queue პლუს retry ნიშნავს, რომ მომხმარებლები სამ კოდს იღებენ; rate limiter-ის გარეშე თავად აწყობთ self-DDoS-ს provider-ზე და throttle-ით ნულამდე დაგცემენ. გავრცელებული ხაფანგია fan-out-ის სინქრონულად კეთება ("უბრალოდ `Promise.all`") — ეს იკავებს connection-ებს, retry არ აქვს და ყველაფერს კარგავს deploy-ისას.

## ტრეიდ-ოფები და ჩავარდნები

- **At-least-once vs exactly-once**: queue-ები იაფად იძლევა at-least-once-ს; "ეფექტურად ერთხელ"-ს ყიდულობთ Redis dedup გასაღებით, არა ძვირადღირებული exactly-once broker-ით.
- **Throughput vs provider-ის ლიმიტები**: worker-ებს უსასრულოდ დაამატებთ, მაგრამ provider-ის quota არის ნამდვილი ჭერი — მოითხოვეთ quota-ის გაზრდა ან წინასწარ გაათბეთ (pre-warm) კამპანიამდე.
- **ჩავარდნა**: Redis არ მუშაობს → გაგზავნები ჩერდება (fail closed, ნუ გამოტოვებთ dedup-ს და ნუ არისკავთ ორმაგებს). აწარმოეთ per-campaign counter, რომ ინციდენტის შემდეგ განაახლოთ (resume), და არა თავიდან დაიწყოთ (restart).

არქიტექტურა

კომპონენტები და ნაკადი

ინტერვიუს პერსპექტივა

ტრეიდ-ოფები და ჩავარდნები

დაკავშირებული კითხვები