Chapter 10 · Hinglish · Sunne-wala Sabak
Notification System — Ek Front Door, Kai Lanes
Push, SMS, email, in-app aur web par har user tak bharose ke saath pahunchna — scale par, time par, aur sirf tab jab user chahe. Niche "Play all" dabaiye aur browser pura chapter padh kar sunayega. Kisi bhi section par "Suniye" se wahin se shuru karein.
▶ Companion slides kholiyeTip: jo voice sabse natural lage wahi chuniye — ek Hindi (hi-IN) ya Indian-English (en-IN) voice aam taur par best chalti hai.
Notification system kya hai Slide 2
Chalo chapter das shuru karte hain, ek notification system. Ise ek simple sender mat samjho, yeh asal mein ek orchestrator hai jo kai channels ke upar baithta hai. Paanch surfaces hoti hain. Ek, mobile push, jo APNs se iPhone par aur FCM se Android par jaati hai. Do, SMS, jo Twilio jaise gateway se phone number par jaati hai, sabse mehngi. Teen, email, SendGrid ya SES se, jiski delivery sender reputation par depend karti hai. Chaar, in-app, jo aapke apne backend par store hoti hai. Aur paanch, web push, browser ke through. Har channel ka apna provider, apna identity model, aur apni cost hai. Push aur in-app lagbhag free hain, SMS mehngi. Sabse achha system har message ko sabse saste channel par bhejta hai jo user ka intent poora kar de.
Requirements Slide 3
Boxes banane se pehle volume aur latency budget tay karo. Functional side simple hai, ek hi API, saare channels, per-channel aur per-topic opt-outs, transactional bhi aur scheduled campaigns bhi, aur server side templates. Asli pressure non-functional side par hai. Traffic bahut bursty hota hai, launch ya incident par spike aata hai. Maan lo ek crore messages per day, yaani average lagbhag ek sau pandrah per second. Par campaign ke waqt peak paanch hazaar per second tak ja sakta hai. Yeh lagbhag chalis guna surge hai, jise system ko bina message khoye absorb karna hai. Transactional ke liye latency do second se kam, campaign ke liye minutes chalega. Aur ek logical event ke duplicate deliveries kabhi nahi honi chahiye.
Ek front door, kai lanes Slide 4
Ab pura pipeline dekho, yahi system hai. Producers, jaise order service ya cron job, ek logical notification ek baar Notification API ko bhejte hain. API authenticate karti hai, user ki preferences check karti hai, aur template render karti hai. Phir message ek queue mein girta hai, jisme har channel ka apna topic hota hai, aur yeh queue burst ko absorb karti hai. Per-channel workers apne provider ke allowed rate par message uthate hain aur provider call mein badal dete hain. Aur har delivery event wapas ek tracking store mein jaata hai. To yaad rakho, produce, phir validate, phir buffer, phir fan out, phir deliver.
Ek API, server-side templates Slide 5
Caller sirf yeh batata hai ki kya hua aur kiske saath hua, ek logical event, na ki ready-made message. Kaise pahunchana hai, yeh notification system decide karta hai. Yeh indirection hi point hai, kyunki copy aur channel routing badalne ke liye har producer ko dobara deploy nahi karna padta. Teen kaam hote hain. Ek, ek event envelope accept karo jisme event, recipient, channels, ek data bag, ek idempotency key aur priority ho. Do, template resolve karo, har channel aur locale ke liye alag, hamesha server par render, kabhi device par nahi. Aur teen, upfront validate karo, unknown event ya missing variable ko wahin reject karo, kyunki sasti failure downstream ki tooti hui send se behtar hai.
Intent aur delivery ke beech queue Slide 6
Producers apne time par chalte hain, providers apne rate limits laga kar rakhte hain. Queue in dono ke beech ka shock absorber hai. Ek taraf bursty, spiky input, doosri taraf steady, rate-limited output, aur queue beech ka difference apne paas rakh leti hai. Producer side benefit yeh hai ki jaise hi message queue mein land karta hai, API success return kar deti hai, producer provider ka wait nahi karta. Consumer side benefit yeh hai ki worker theek apne provider ke allowed rate par pull karta hai, aur backpressure automatic hota hai, worker slow to queue badhti hai, catch up kare to queue drain hoti hai. Queue ko user id se partition karo, taaki ek user ka order ek channel ke andar bana rahe.
Har provider apni alag duniya Slide 7
Bahar ki saari messy reality channel workers mein rehti hai. Har worker ek provider se ek patle adapter ke through baat karta hai aur baaki system ko uski quirks se bacha leta hai, jaise payload size, carrier filtering, ya warm-up rules. Adapter ke upar ek uniform interface hota hai, send, cancel, status. Do cheezein important hain. Ek, per-provider rate bucket, yaani har worker apna token bucket lagata hai, bilkul chapter chaar wale rate limiter ki tarah. Agar budget teen sau email per second hai, to worker teen sau par hi rakhega chahe queue mein lakhon message ho. Aur do, failover provider, khaas kar SMS ke liye, taaki primary down ho to ek doosra provider deliveries chalate rahe.
Retries, backoff aur dead-letter queue Slide 8
Providers fail karte hain, network blip karta hai. Worker ka kaam yeh jaanna hai ki kaun si failure retry ke layak hai, kitni der wait karna hai, aur jo bilkul nahi jaati unka kya karna hai. Rule simple hai. Do, do, ya do sau wali success matlab delivered, kaam khatam. Char sau wali error, jaise bad token ya unverified sender, matlab message hi kharab hai, ise drop karo aur stale token clean karo, retry karne se sirf quota barbaad hoga. Aur paanch sau, char sau untees, ya timeout matlab retry karo. Retry exponential backoff se ho, jaise ek second, phir chaar, phir solah, phir chausath second, ke saath thoda random jitter taaki saare workers ek saath ek hi wounded provider par na tootein. Paanch ya chhah attempt ke baad message dead-letter queue mein jaata hai, jise engineer inspect aur replay kar sakein. DLQ badhe to alert aata hai. Koi message chupchap kabhi drop nahi hota.
Deduplication aur idempotency Slide 9
Distributed systems retry karte hain, caller scripts retry karte hain, queues redeliver karti hain. System ko guarantee deni hai ki user har logical message zyada se zyada ek baar dekhe. Iska tool hai ek stable idempotency key jo producer chunta hai, jaise order A-saat-saat-ek-shunya shipped. Ise do jagah check karo. Ek, API par, ek fast Redis set-if-not-exists, key par, jiska TTL chaubees se athtalis ghante ho, taaki usi key wala doosra request original response wapas de. Do, worker par, provider call se theek pehle, user, channel aur key se, taaki queue ki redelivery bhi pakdi jaaye. Aur key logical event ko encode kare, request ko nahi, taaki do alag services ka order shipped ek hi key banaye aur duplicate suppress ho jaaye. Queues by default at-least-once deti hain, key use at-most-once bana deti hai.
User preferences ek first-class gate Slide 10
Ek perfectly delivered notification bhi galat hai agar user use nahi chahta tha. Isliye preferences ko centrally, request path mein enforce karo, na ki baad mein kisi filter mein. Chaar gates order mein chalte hain. Ek, channel opt-out, agar user ne poora channel band kar rakha hai to drop. Do, topic muted, har event par ek topic tag hota hai, transactional rakho par marketing mute karo. Teen, quiet hours, user ki local raat mein sends ko subah tak defer karo, sirf allowed high-priority events chhod kar. Chaar, frequency cap, ek counter per user per channel, daily ya weekly limit hit ho to skip. Aur inke upar ek regulatory floor hai, jaise GDPR aur CAN-SPAM, jo explicit consent, har email mein working unsubscribe link, aur request par history deletion maangta hai.
Tracking — pahuncha ya nahi Slide 11
Har send ek stream of events chhodta hai, delivered, opened, aur clicked, jo ek hi pipeline mein jaate hain. Is loop ke bina system andha hai aur channel routing sirf guesswork reh jaati hai. Wahi event stream kai jagah feed karta hai, realtime dashboards, warehouse jaise BigQuery ya Snowflake, frequency-cap counters, aur token cleanup job. Loop close karna zaroori hai, ek bounce email address clean karta hai, ek unregistered token device list se hatata hai, aur warehouse analytics wapas routing decisions ko feed karti hai ki agli baar kaunsa channel best rahega. Ek reality yaad rakho, email open ek tracking pixel se aata hai jise kai clients block kar dete hain, isliye woh metric ek lower bound hai, jabki push tap reliable hota hai.
Principles Slide 12
To chhah principles yaad rakho. Ek, queue se decouple karo, yahi design ka dil hai. Do, provider ki quirks ko edges par rakho, core ek clean shape bole. Teen, transient ko retry karo aur baaki ko dead-letter, kabhi chupchap drop mat karo. Chaar, idempotency key at-least-once ko khatam karti hai, API aur worker dono par check karo. Paanch, preferences ek gate hai, opt-out, topic mute, quiet hours aur frequency cap request path mein rehte hain. Aur chhah, tracking se loop close karo, har delivery ek event chhodti hai jo dashboards, caps, cleanup aur routing chalati hai.
Aage kya
Bas, yahi hai chapter das. Ek kaam karo, koi bhi app chuno jise aap use karte ho, aur soncho ki uska order-shipped ya login-alert notification kaise banega. Producer se API, phir queue, phir worker, phir provider, har step par yeh poochte hue ki spike kahan absorb hoga, duplicate kaise rukega, aur user ki preference kahan check hogi. Method ko reflex bana lo. Kuch bhi confuse kare to mujhse pooch lena. Agle chapter mein hum ek news feed system design karenge.