Articles

Blogs

MCQ

SQL

Q&A

Tools

Tags

Jobs

News

Community

LogIn

Email

Password

Show Password

Forget Password

I don't have account.Sign Up!

Login

‹ ›

‹ ›

‹ ›

‹ ›

Sponsored -53%

Zebronics #1 Best Seller

ZEBRONICS Blanc Slim Wireless Mouse — Rechargeable, BT + 2.4GHz (Black)

Up to 1600 DPI · Silent clicks · 63g · Multicolor LED

★★★★★★★★★★ 4.0 (9,512) 5K+ bought last month

₹376 M.R.P. ₹799Save ₹423

Buy Now →

Adℹ

✕

Kotak Mahindra Bank SDE-1 Round 3 Interview Experience – LLD Round (Notification Service Design)

Kunal Dixit

Last Updated : 04 June 2026

559 Views

#lld

#interview-experience

#interview-preparation

#system-design-interview

#interview-questions

Adℹ

One of the most interesting rounds in my Kotak interview process was the Low-Level Design round. Unlike traditional DSA interviews, this round focused on designing a real-world system and evaluating how I structure classes, APIs, business logic and extensibility.

The interviewer asked me to design and implement a Notification Service that could send notifications through multiple channels such as Email, WhatsApp and SMS. At first glance the problem looked simple, but as the discussion progressed it became clear that the interviewer was less interested in sending notifications and more interested in understanding whether I could design a maintainable, scalable and extensible system.

The biggest challenge was not the notification delivery itself. The challenge was designing a flexible template framework that could support multiple notification types, different communication channels, dynamic placeholders, validation and future extensibility without requiring major code changes.

Problem Statement

The system should support two APIs:

1. Template Registration

Allows businesses to register notification templates.

Example:

OTP Template

Required Inputs:

emailAddress
mobileNumber
name
otp

// Email Template:

Subject: OTP Information

Hi {name},

This is your OTP {otp}

// SMS Template:

OTP Information {otp} for login.

Promotion Template

Required Inputs:

emailAddress
mobileNumber
couponCode

// Email Template:

Subject: Promotion

Hi,

Your coupon code is {couponCode}

// SMS Template:

Coupon code: {couponCode}

2. Template Invocation

Example Request:

{
  "templateName": "OTP",
  "input": {
    "emailAddress": "user@gmail.com",
    "mobileNumber": "9999999999",
    "name": "Raj",
    "otp": "123456"
  }
}

Expected Output:

// Email:

Subject: OTP Information

Hi Raj,

This is your OTP 123456

// SMS:

OTP Information 123456 for login.
Requirements Clarification

Before jumping into design, I clarified a few requirements:

• Functional Requirements
• Register templates dynamically
• Support multiple notification channels
• Replace placeholders dynamically
• Validate mandatory fields
• Send notifications through all configured channels
• Store templates in memory
• Non-Functional Requirements
• Extensible for future channels
• Easy to maintain
• Low coupling
• High cohesion
• Thread-safe design
• Easy testing

These discussions are usually where interviewers start evaluating design maturity.

High-Level Architecture

I proposed dividing responsibilities into separate components.

                Client
                   |
                   v
        NotificationService
                   |
     ----------------------------
     |            |             |
     v            v             v
TemplateRepo  TemplateEngine  SenderFactory
                                   |
                   --------------------------------
                   |              |              |
                   v              v              v
             EmailSender     SmsSender   WhatsappSender

Instead of building one giant NotificationService class, every component owns a single responsibility. This follows the Single Responsibility Principle and keeps the design maintainable as the system grows.

Core Domain Models

Notification Channel

public enum Channel {
    EMAIL,
    SMS,
    WHATSAPP
}

This provides type safety and avoids string comparisons throughout the codebase.

Template

A template represents a notification definition.

public class Template {
    private String templateName;
    private Set<String> requiredFields;
    private Map<Channel, ChannelTemplate> channelTemplates;
}

Example:

OTP Template
├── Email Template
├── SMS Template
└── WhatsApp Template

The advantage is that adding a new channel does not require modifying existing templates.

Channel Template

public class ChannelTemplate {
    private String subject;
    private String body;
}

For SMS and WhatsApp, subject can remain null. This model keeps the design generic.

Template Repository

Since the interviewer explicitly mentioned using local data structures, I proposed an in-memory repository.

public class TemplateRepository {
    private final Map<String, Template> templates =
            new ConcurrentHashMap<>();

}

Methods:

void save(Template template);
Template get(String templateName);

Using ConcurrentHashMap makes the repository thread-safe for concurrent registrations and invocations.

Template Engine

One of the most important pieces of the design is the template rendering engine. Its responsibility is replacing placeholders.

Input:

Hi {name}

Your OTP is {otp}

Data:

{
  "name":"Raj",
  "otp":"123456"
}

Output:

Hi Raj

Your OTP is 123456

Implementation:

public class TemplateEngine {

    public String render(
            String template,
            Map<String, String> values) {
        String result = template;
        for (Map.Entry<String, String> entry : values.entrySet()) {
            result = result.replace(
                    "{" + entry.getKey() + "}",
                    entry.getValue());
        }
        return result;
    }
}

This component is completely reusable and independent from notification delivery.

Notification Sender Strategy

This is where good LLD design begins to shine. Instead of writing:

if(channel.equals("EMAIL")) {
   ...
}
else if(channel.equals("SMS")) {
   ...
}
else if(channel.equals("WHATSAPP")) {
   ...
}

I introduced the Strategy Pattern.

Common Interface

public interface NotificationSender {
    void send(NotificationRequest request);
}

Email Sender

public class EmailSender
        implements NotificationSender {
    @Override
    public void send(NotificationRequest request) {
        System.out.println(
                "Sending Email to "
                        + request.getEmailAddress());
    }
}

SMS Sender

public class SmsSender
        implements NotificationSender {
    @Override
    public void send(NotificationRequest request) {
        System.out.println(
                "Sending SMS to "
                        + request.getMobileNumber());
    }
}

WhatsApp Sender

public class WhatsappSender
        implements NotificationSender {
    @Override
    public void send(NotificationRequest request) {
        System.out.println(
                "Sending WhatsApp to "
                        + request.getMobileNumber());
    }
}

Each channel owns its own delivery logic.

Sender Factory

To avoid large switch statements:

public class SenderFactory {
    private final Map<Channel,
            NotificationSender> senders;
    public NotificationSender getSender(
            Channel channel) {
        return senders.get(channel);
    }
}

This follows the Open-Closed Principle. Tomorrow if business asks for:

• Push Notification
• Slack
• Telegram
• Teams

we simply add:

class PushSender
implements NotificationSender

without changing existing code.

API 1 – Register Template

POST /templates

Request:

{
  "templateName":"OTP",
  ...
}

Service Layer:

public void registerTemplate(
        Template template) {
    repository.save(template);
}

Complexity:

• Time : O(1)
• Space: O(1)

API 2 – Invoke Template

POST /notifications/send

Flow:

1. Fetch Template
2. Validate Inputs
3. Render Template
4. Send Notification

Implementation:

public void invoke(
        String templateName,
        Map<String,String> input) {
    Template template =
            repository.get(templateName);
    validate(template, input);
    for(var channelEntry :
            template.getChannelTemplates()
                    .entrySet()) {

        Channel channel =
                channelEntry.getKey();

        ChannelTemplate ct =
                channelEntry.getValue();

        String body =
                engine.render(
                        ct.getBody(),
                        input);
        NotificationSender sender =
                factory.getSender(channel);
        sender.send(
                buildRequest(body, input));
    }
}

This orchestration layer remains extremely clean because responsibilities are delegated to specialized components.

Production-Level Enhancements

Toward the end of the interview, I discussed how this design could evolve in a real production environment.

Asynchronous Processing

Instead of sending notifications synchronously:

API
 ↓
Send Email
 ↓
Send SMS
 ↓
Return Response

Use:

API
 ↓
Kafka
 ↓
Notification Workers
 ↓
Email/SMS Providers

This improves reliability and latency.

Retry Mechanism

Failures are inevitable. For example:

• Email Provider Down
• Network Timeout
• WhatsApp API Failure

Introduce:

• Retry Queue
• Exponential Backoff
• Dead Letter Queue

for failed notifications.

Provider Abstraction

Today:

• Email → SES
• SMS → Twilio
• WhatsApp → Meta

Tomorrow:

• Email → SendGrid
• SMS → Gupshup
• WhatsApp → Infobip

Business logic should remain unchanged.

Audit Logs

Every notification should be tracked.

NotificationAudit

Fields:

• NotificationId
• TemplateName
• Channel
• Status
• RetryCount
• CreatedAt

This helps debugging and compliance.

Key Learnings

This round taught me that interviewers are usually not evaluating whether you can write Java classes. They are evaluating whether you can model a real business problem using good software engineering principles. The strongest aspects of this solution are:

• Single Responsibility Principle
• Open Closed Principle
• Strategy Pattern
• Factory Pattern
• Template Engine Separation
• Thread-safe Repository
• Extensible Architecture
• Production Readiness Considerations

Looking back, the interviewer was primarily interested in the service layer implementation, template rendering flow and how new notification channels could be added without changing existing code. Candidates who focus only on class diagrams often miss these discussions, while candidates who explain design decisions, trade-offs and future extensibility generally perform much better in Low-Level Design interviews.

Recommended Interview Experience

Disney+ Hotstar SDE-2 Interview Experience | Coding + System Design + Techno Managerial

Uber Senior Software Engineer Interview Experience | Real Interview Questions, System Design & Preparation Guide

Meta Business Engineer (L4 → L5 Consideration) Interview Experience

Rupeek Android Developer Interview Experience | Real Questions Asked, Preparation Tips & Complete Process

Rupeek SDE-3 Interview Experience (3 Rounds ~ Coding, LLD & HLD)

WheelsEye Backend Engineer Interview Experience | DSA Questions, System Design, Backend Deep Dive

Wise Software Engineer Interview Experience | DSA, System Design, Product Thinking

Yext SDE 1 Interview Experience – Complete DSA Questions, Debugging Round, API Challenge & HR Round

Uber SDE 2 Interview Experience (5 Rounds, Selected)

Adobe Software Engineer 2 Interview Experience

Volvo Cars Full Stack Developer Interview Experience (Selected)

Wayfair SDE Interview Experience

Wells Fargo SDE I Interview Experience

My Vegapay Backend Engineer (SDE 2) Interview Experience (Rejected)

Trending Developer Reads

Amazon SDE-2 Interview Experience (3 Years Experience)

Cursor vs Copilot : Which AI Coding Assistant Wins in 2025?

Spinny SDE-1 Interview Experience (Selected)

System Design Interview – BIGGEST Mistakes to Avoid

Top 50+ SQL Interview Questions and Answers for Intermediate to Advanced

DSA Patterns for Coding Interviews: Complete LeetCode Roadmap (Beginner to Advanced)

My Adobe SDE Interview Experience (Aug 2026) 5 Rounds, Selected

Uber SDE 2 Interview Experience (5 Rounds, Selected) - Complete DSA Questions with solution, System Design & Managerial Round

Amazon SDE II Interview Experience (Bangalore, Selected) ~ Aug 2026

Blinkit (Eternal) SDE-1 Interview Experience (June 2026) – Offer Received

Responses (0)

Write a response

Hide Comments

No Comments yet.

‹ ›

‹ ›

‹ ›

‹ ›

Sponsored -53%

Zebronics #1 Best Seller

ZEBRONICS Blanc Slim Wireless Mouse — Rechargeable, BT + 2.4GHz (Black)

Up to 1600 DPI · Silent clicks · 63g · Multicolor LED

★★★★★★★★★★ 4.0 (9,512) 5K+ bought last month

₹376 M.R.P. ₹799Save ₹423

Buy Now →

‹ ›

‹ ›

‹ ›

‹ ›

Sponsored -34%

iQOO Amazon's Choice

iQOO Z10 Lite 5G — Cyber Green, 4GB RAM, 128GB Storage

Dimensity 6300 · 50MP Sony AI Camera · 6000 mAh · IP64

★★★★★★★★★★ 4.0 (2,052) 500+ bought last month

₹18,997 M.R.P. ₹28,999Save ₹10,002

Buy Now →

\n \n \n \n \n

One of the most interesting rounds in my Kotak interview process was the Low-Level Design round. Unlike traditional DSA interviews, this round focused\non designing a real-world system and evaluating how I structure classes, APIs, business logic and extensibility.

The interviewer asked me to design and implement a Notification Service that could send notifications through multiple channels such as Email,\nWhatsApp and SMS. At first glance the problem looked simple, but as the discussion progressed it became clear that the interviewer was less interested\nin sending notifications and more interested in understanding whether I could design a maintainable, scalable and extensible system.

The biggest challenge was not the notification delivery itself. The challenge was designing a flexible template framework that could support multiple\nnotification types, different communication channels, dynamic placeholders, validation and future extensibility without requiring major code changes.

Problem Statement

The system should support two APIs:

1. Template Registration

Allows businesses to register notification templates.

Example:

OTP Template

\nRequired Inputs:\n\nemailAddress\nmobileNumber\nname\notp\n

\n// Email Template:\n\nSubject: OTP Information\n\nHi {name},\n\nThis is your OTP {otp}\n\n// SMS Template:\n\nOTP Information {otp} for login.\n\n

Promotion Template

\nRequired Inputs:\n\nemailAddress\nmobileNumber\ncouponCode\n

\n// Email Template:\n\nSubject: Promotion\n\nHi,\n\nYour coupon code is {couponCode}\n\n// SMS Template:\n\nCoupon code: {couponCode}\n

2. Template Invocation

\nExample Request:\n\n{\n  \"templateName\": \"OTP\",\n  \"input\": {\n    \"emailAddress\": \"user@gmail.com\",\n    \"mobileNumber\": \"9999999999\",\n    \"name\": \"Raj\",\n    \"otp\": \"123456\"\n  }\n}\n

Expected Output:

\n// Email:\n\nSubject: OTP Information\n\nHi Raj,\n\nThis is your OTP 123456\n\n// SMS:\n\nOTP Information 123456 for login.\nRequirements Clarification\n

Before jumping into design, I clarified a few requirements:

\n
• Functional Requirements
\n
• Register templates dynamically
\n
• Support multiple notification channels
\n
• Replace placeholders dynamically
\n
• Validate mandatory fields
\n
• Send notifications through all configured channels
\n
• Store templates in memory
\n
• Non-Functional Requirements
\n
• Extensible for future channels
\n
• Easy to maintain
\n
• Low coupling
\n
• High cohesion
\n
• Thread-safe design
\n
• Easy testing
\n

These discussions are usually where interviewers start evaluating design maturity.

High-Level Architecture

I proposed dividing responsibilities into separate components.

\n                Client\n                   |\n                   v\n        NotificationService\n                   |\n     ----------------------------\n     |            |             |\n     v            v             v\nTemplateRepo  TemplateEngine  SenderFactory\n                                   |\n                   --------------------------------\n                   |              |              |\n                   v              v              v\n             EmailSender     SmsSender   WhatsappSender\n

Instead of building one giant NotificationService class, every component owns a single responsibility.\nThis follows the Single Responsibility Principle and keeps the design maintainable as the system grows.

Core Domain Models

Notification Channel

\npublic enum Channel {\n    EMAIL,\n    SMS,\n    WHATSAPP\n}\n

This provides type safety and avoids string comparisons throughout the codebase.

Template

A template represents a notification definition.

\npublic class Template {\n    private String templateName;\n    private Set<String> requiredFields;\n    private Map<Channel, ChannelTemplate> channelTemplates;\n}\n

Example:

\nOTP Template\n├── Email Template\n├── SMS Template\n└── WhatsApp Template\n

The advantage is that adding a new channel does not require modifying existing templates.

Channel Template

\npublic class ChannelTemplate {\n    private String subject;\n    private String body;\n}\n

For SMS and WhatsApp, subject can remain null.\nThis model keeps the design generic.

Template Repository

Since the interviewer explicitly mentioned using local data structures, I proposed an in-memory repository.

\npublic class TemplateRepository {\n    private final Map<String, Template> templates =\n            new ConcurrentHashMap<>();\n\n}\n

Methods:

\nvoid save(Template template);\nTemplate get(String templateName);\n

Using ConcurrentHashMap makes the repository thread-safe for concurrent registrations and invocations.

Template Engine

One of the most important pieces of the design is the template rendering engine.\nIts responsibility is replacing placeholders.

Input:

\nHi {name}\n\nYour OTP is {otp}\n

Data:

\n{\n  \"name\":\"Raj\",\n  \"otp\":\"123456\"\n}\n

Output:

\nHi Raj\n\nYour OTP is 123456\n

Implementation:

\npublic class TemplateEngine {\n\n    public String render(\n            String template,\n            Map<String, String> values) {\n        String result = template;\n        for (Map.Entry<String, String> entry : values.entrySet()) {\n            result = result.replace(\n                    \"{\" + entry.getKey() + \"}\",\n                    entry.getValue());\n        }\n        return result;\n    }\n}\n

This component is completely reusable and independent from notification delivery.

Notification Sender Strategy

This is where good LLD design begins to shine.\nInstead of writing:

\nif(channel.equals(\"EMAIL\")) {\n   ...\n}\nelse if(channel.equals(\"SMS\")) {\n   ...\n}\nelse if(channel.equals(\"WHATSAPP\")) {\n   ...\n}\n

I introduced the Strategy Pattern.

Common Interface

\npublic interface NotificationSender {\n    void send(NotificationRequest request);\n}\n

Email Sender

\npublic class EmailSender\n        implements NotificationSender {\n    @Override\n    public void send(NotificationRequest request) {\n        System.out.println(\n                \"Sending Email to \"\n                        + request.getEmailAddress());\n    }\n}\n

SMS Sender

\npublic class SmsSender\n        implements NotificationSender {\n    @Override\n    public void send(NotificationRequest request) {\n        System.out.println(\n                \"Sending SMS to \"\n                        + request.getMobileNumber());\n    }\n}\n

WhatsApp Sender

\npublic class WhatsappSender\n        implements NotificationSender {\n    @Override\n    public void send(NotificationRequest request) {\n        System.out.println(\n                \"Sending WhatsApp to \"\n                        + request.getMobileNumber());\n    }\n}\n

Each channel owns its own delivery logic.

Sender Factory

To avoid large switch statements:

\npublic class SenderFactory {\n    private final Map<Channel,\n            NotificationSender> senders;\n    public NotificationSender getSender(\n            Channel channel) {\n        return senders.get(channel);\n    }\n}\n

This follows the Open-Closed Principle.\nTomorrow if business asks for:

\n
• Push Notification
\n
• Slack
\n
• Telegram
\n
• Teams
\n

we simply add:

\nclass PushSender\nimplements NotificationSender\n

without changing existing code.

API 1 – Register Template

POST /templates

Request:

\n{\n  \"templateName\":\"OTP\",\n  ...\n}\n

Service Layer:

\npublic void registerTemplate(\n        Template template) {\n    repository.save(template);\n}\n

Complexity:

\n
• Time : O(1)
\n
• Space: O(1)
\n

API 2 – Invoke Template

POST /notifications/send

Flow:

\n
1. Fetch Template
\n
2. Validate Inputs
\n
3. Render Template
\n
4. Send Notification
\n

Implementation:

\npublic void invoke(\n        String templateName,\n        Map<String,String> input) {\n    Template template =\n            repository.get(templateName);\n    validate(template, input);\n    for(var channelEntry :\n            template.getChannelTemplates()\n                    .entrySet()) {\n\n        Channel channel =\n                channelEntry.getKey();\n\n        ChannelTemplate ct =\n                channelEntry.getValue();\n\n        String body =\n                engine.render(\n                        ct.getBody(),\n                        input);\n        NotificationSender sender =\n                factory.getSender(channel);\n        sender.send(\n                buildRequest(body, input));\n    }\n}\n

This orchestration layer remains extremely clean because responsibilities are delegated to specialized components.

Production-Level Enhancements

Toward the end of the interview, I discussed how this design could evolve in a real production environment.

Asynchronous Processing

Instead of sending notifications synchronously:

\nAPI\n ↓\nSend Email\n ↓\nSend SMS\n ↓\nReturn Response\n

Use:

\nAPI\n ↓\nKafka\n ↓\nNotification Workers\n ↓\nEmail/SMS Providers\n

This improves reliability and latency.

Retry Mechanism

Failures are inevitable.\nFor example:

\n
• Email Provider Down
\n
• Network Timeout
\n
• WhatsApp API Failure
\n

Introduce:

\n
• Retry Queue
\n
• Exponential Backoff
\n
• Dead Letter Queue
\n

for failed notifications.

Provider Abstraction

Today:

\n
• Email → SES
\n
• SMS → Twilio
\n
• WhatsApp → Meta
\n

Tomorrow:

\n
• Email → SendGrid
\n
• SMS → Gupshup
\n
• WhatsApp → Infobip
\n

Business logic should remain unchanged.

Audit Logs

Every notification should be tracked.

NotificationAudit

Fields:

\n
• NotificationId
\n
• TemplateName
\n
• Channel
\n
• Status
\n
• RetryCount
\n
• CreatedAt
\n

This helps debugging and compliance.

Key Learnings

This round taught me that interviewers are usually not evaluating whether you can write Java classes. They are evaluating whether you can model a real\nbusiness problem using good software engineering principles.\nThe strongest aspects of this solution are:

\n
• Single Responsibility Principle
\n
• Open Closed Principle
\n
• Strategy Pattern
\n
• Factory Pattern
\n
• Template Engine Separation
\n
• Thread-safe Repository
\n
• Extensible Architecture
\n
• Production Readiness Considerations
\n

Looking back, the interviewer was primarily interested in the service layer implementation, template rendering flow and how new notification channels\ncould be added without changing existing code. Candidates who focus only on class diagrams often miss these discussions, while candidates who explain\ndesign decisions, trade-offs and future extensibility generally perform much better in Low-Level Design interviews.

Recommended Interview Experience