Design A Notification System - Object-Oriented Design

Requirements

To design a notification system, we must first understand how it will be used. The system should:

Managing user preferences for notification types and delivery channels.
Scheduling notifications across various time zones and ensuring they are sent at the right time.
Implementing robust retry mechanisms with strategies like exponential backoff and fallback channels.
Providing APIs with authentication for external systems to send notifications.
Logging errors, tracking delivery status, and processing delivery reports.
Supporting union and intersection of channels to handle multi-channel notifications.
Handling peak loads with caching, load balancing, and distributed processing.
Preventing duplicate notifications and addressing edge cases like time zones and third-party failures.

Define Core Objects

User

UserPreference

Notification

NotificationStrategy

EmailNotification

SMSNotification

PushNotification

NotificationService

Scheduler

RetryMechanism

Analyze Relationships

User and Preferences: Preferences are stored in a database, fetched at runtime, and cached for performance.
Notification and Status: Each notification tracks its delivery status, updated asynchronously as delivery reports are processed.
Notification and Channels: Union and intersection logic determines which channels are used based on preferences.
RetryManager and Notification: Retried notifications are updated with attempt counts and final statuses.
Scheduler and Time Zones: Notifications are scheduled based on user time zones, considering daylight saving adjustments.

Establish Hierarchy

Channel Hierarchy: Create a base Channel class with common attributes and methods. Derive EmailChannel, SMSChannel, and PushChannel for channel-specific logic.
Notification Type Hierarchy: Define a base Notification class and extend it for different types like TransactionalNotification and PromotionalNotification.

Design Patterns

Channel Hierarchy: Base Channel class with specific implementations for EmailChannel, SMSChannel, PushChannel, etc.
Notification Type Hierarchy: Extendable base Notification class for different notification types.
Retry Strategies: Strategy pattern for retry logic, allowing dynamic injection of strategies (e.g., exponential backoff).

Define Class Members (write code)

public enum NotificationType{
    Sms,
    Push,
    Email
}
public enum NotificationFrequency{
Daily,
Weekly,
Immediately
}
public enum Status{
Pending,
Sent,
Failed
}
public class User{
private String userId;
private String userName;
private UserPreference preferences;
public User(String userId,String userName){
this.userId=userId;
this.userName=userName;
}
public UserPreference getUserPreference(){
return preferences;
}
public void setUserPreference(UserPreference pref){
this.preferences=pref;
}
}
public class UserPreference{
private List&lt;NotificationType&gt; types;
private String frequency;
private int quietHours;

//setters for types,frequency,quietHours

}
public class Notification{
private String id;
private String content;
private NotificationType type;
private Status status;
//setters and constructors

}
public interface NotificationStrategy{
public void send(User user,Notification notification);
}
public class SmsNotification implements NotificationStrategy{
@Override
public void send(User user,Notification notification){
// logic to send sms
}
}
public class PushNotification implements NotificationStrategy{
@Override
public void send(User user,Notification notification){
// logic to send sms
}
}
public class EmailNotification implements NotificationStrategy{
@Override
public void send(User user,Notification notification){
// logic to send sms
}
}
public class NotificationService{
NotificationStrategy strategy;

public NotificationService(NotificationStrategy strategy){
  this.strategy=strategy;
}

public void setStrategy(NotificationStrategy strategy){
  this.strategy=strategy;
}

public void sendNotification(User user,Notification notification){
  strategy.send(user,notification);
}

}

Adhere to SOLID Guidelines

Check and explain whether your design adheres to solid principles (Ask interviewer what SOLID principle is if you can not recall it.)...

Consider Scalability and Flexibility

Explain how your design can handle changes in scale and whether it would be easily to extend with new functionalities...

Create/Explain your diagram(s)

Try creating a class, flow, state and/or sequence diagram using the diagramming tool. Mermaid flow diagrams can be used to represent system use cases. You can ask the interviewer bot to create a starter diagram if unfamiliar with the tool. Briefly explain your diagrams if necessary...

Future improvements

Critically examine your design for any flaws or areas for future improvement...