Πώς θα σχεδιάζατε μια υπηρεσία ειδοποιήσεων (notification service) για ολόκληρη την εταιρεία;

Question

IT Interview Practice · Accepted Answer

Χτίστε μία υπηρεσία που κάθε ομάδα καλεί με ένα **τύπο ειδοποίησης + παραλήπτη**, και αφήστε την υπηρεσία να αναλύσει channel, template, προτιμήσεις χρήστη, και προτεραιότητα. Η κρίσιμη σχεδιαστική κίνηση είναι οι **priority lanes** — ένα OTP δεν μπορεί να περιμένει πίσω από ένα marketing blast 2 εκατομμυρίων χρηστών.

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

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

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

- **Το Notify API** παίρνει ένα typed request: `{type: "otp", user, data}`. Οι callers ποτέ δεν διαλέγουν channel ούτε γράφουν κείμενο — η υπηρεσία κατέχει αυτό, οπότε μια αλλαγή template κυκλοφορεί μία φορά.
- **Type → policy**: κάθε **type** αντιστοιχεί σε μια policy. *OTP* είναι υψηλής προτεραιότητας, SMS+Push, αγνοεί το marketing opt-out, λήγει σε 60s. *Transactional* (απόδειξη, password reset) είναι υψηλής, σέβεται τις channel prefs. *Marketing* είναι χαμηλής, bulk lane, τηρεί αυστηρά το opt-out και τις quiet hours.
- **Οι priority lanes** είναι ξεχωριστά Kafka topics με ξεχωριστά consumer groups. Η high lane παραμένει σχεδόν άδεια και αδειάζει σε milliseconds· η bulk lane μπορεί να συσσωρευτεί για λεπτά χωρίς να αγγίξει το latency του OTP. Αυτή είναι η μοναδική πιο σημαντική απόφαση.
- **Η preference service** ελέγχεται ανά παραλήπτη: opted out; quiet hours; per-channel toggle; frequency cap; Marketing που παραβιάζει μια προτίμηση απορρίπτεται εδώ.
- **Η template engine** αποδίδει localized περιεχόμενο από ένα versioned template + variables, οπότε το κείμενο και ο κώδικας είναι decoupled.
- **Οι channel adapters** τυλίγουν FCM/APNs, SendGrid, Twilio πίσω από ένα interface, καθένας με τον δικό του rate limiter, retry, και DLQ (η ίδια πειθαρχία fan-out με οποιονδήποτε bulk sender).

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

Οι συνεντευκτές διερευνούν αν διαχωρίζετε τα **concerns**: πολλοί υποψήφιοι χτίζουν ένα monolith που στέλνει email απευθείας, και μετά ανακαλύπτουν ότι πλημμύρες marketing καθυστερούν τα OTP. Το να κατονομάζετε *priority lanes*, *preference enforcement*, και *idempotency keys* (ώστε ένα retried request να μη διπλο-ειδοποιεί) είναι το senior signal. Το καλό προσθέτει channels· το εξαιρετικό εξηγεί γιατί OTP και marketing δεν πρέπει ποτέ να μοιράζονται ουρά και πώς λειτουργεί μια **fallback chain** (Push αποτυγχάνει → SMS).

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

- **Μία υπηρεσία vs per-team**: η συγκέντρωση δίνει συνεπείς prefs, throttling, και audit, αλλά γίνεται κρίσιμη εξάρτηση — πρέπει να είναι HA, αλλιώς μια διακοπή login OTP μπλοκάρει ολόκληρη την εταιρεία.
- **Real-time vs κόστος**: το SMS είναι ακριβό και αργό· προτιμήστε Push/In-App και κάντε fallback σε SMS μόνο για high-value types.
- **Αποτυχία**: μια διακοπή provider ενεργοποιεί τη fallback chain, όχι μια hard fail. Τα **dedup keys** αποτρέπουν μια ξανα-παράδοση της ουράς από το να στείλει ένα OTP δύο φορές. Παρακολουθήστε delivery SLOs ανά type — ένα καθυστερημένο marketing email είναι εντάξει, ένα καθυστερημένο OTP είναι incident.

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

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

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

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

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