Arpit's Newsletter read by 38000+ engineers
Weekly essays on real-world system design, distributed systems, or a deep dive into some super-clever algorithm.
Delivery of notifications is critical for a FinTech company like Razorpay because it is a way to notify customers about their transactions and connect with external systems through Webhooks.
So, how did they design their notification system? let’s find out
Upon every transaction, an event/message was sent to SQS (message broker) which was consumed by a worker that then fanned out the notification through different channels.
Because we want to guarantee delivery, a state was maintained in the database that tells if the notification was successfully sent or not (esp via Webhook).
Hence, there is a component called Scheduler that pulls the unsent notifications from this database and re-queues it in SQS; thus guaranteeing the delivery.
In order to ensure that one type of notification does not affect others, every notification type is classified with some priority and depending on which they are pushed to the corresponding SQS queue.
This ensures that a huge marketing campaign does not affect transactional messages.
To ensure mass notification from one customer does not affect others, we add Rate Limiter that would limit the notifications per customer and per type ensuring that critical notifications always meet the SLA.
We could not scale workers because of high DB load, and hence instead of doing a sync write to the database, the notifications that are unsent and need to be retried are pushed in a sync way to the database.
Because of this async write, we ensure that we write to the database in a staggered way and not put unnecessary load on it.
To ensure we are maintaining our SLA, we have to exhaustively monitor the entire infra for any anomaly; the metrics like - health of the infra, success rate of delivery, and SLA.
Here's the video ⤵
Super practical courses, with a no-nonsense approach, are designed to spark engineering curiosity and help you ace your career.
An in-depth, self-paced, and on-demand course that for early engineers to become great at designing scalable, available, and extensible systems at scale.
A masterclass that helps experienced engineers become great at designing scalable, fault-tolerant, and highly available systems.
A course that helps covers Redis internals by reimplementing its core features like - event loop, serialization protocol, pipelining, eviction, and transactions.
Arpit's Newsletter read by 38000+ engineers
Weekly essays on real-world system design, distributed systems, or a deep dive into some super-clever algorithm.