Observer Design Pattern in Java
Learn Observer Design Pattern in Java with Publisher-Subscriber architecture, event-driven systems, Spring Events, Kafka messaging, real-time notifications, UML diagrams, Java implementation, enterprise use cases, and interview questions.
What You Will Learn
- What is Observer Pattern?
- Why Observer Pattern is Needed
- Publisher Subscriber Architecture
- Event Driven Systems
- Java Implementation
- Spring Event Examples
- Kafka Event Architecture
- Real-Time Notification Systems
- Enterprise Use Cases
- Benefits and Limitations
- Interview Questions
Introduction
Modern enterprise applications are event-driven.
Examples:
Order Placed
Payment Completed
Claim Approved
Customer Registered
Transaction Processed
When an event occurs:
Send Email
Update Inventory
Generate Invoice
Send Notification
Update Analytics
Without Observer Pattern:
Order Service
↓
Email Service
↓
Inventory Service
↓
Analytics Service
↓
Notification Service
The Order Service becomes tightly coupled.
Observer Pattern solves this problem.
What is Observer Pattern?
Observer is a Behavioral Design Pattern that defines a one-to-many dependency between objects.
When one object changes:
Subject Changes
↓
All Observers Notified
Automatically.
Purpose of Observer Pattern
Primary goal:
Event Driven Communication
Without Tight Coupling
Real World Analogy
YouTube Channel Subscription.
When a creator uploads a video:
Creator
↓
New Video
↓
Subscribers Notified
Subscribers are Observers.
Channel is the Subject.
Problem Without Observer
flowchart LR
A[Order Service]
B[Email Service]
C[Inventory Service]
D[Analytics Service]
E[Notification Service]
A --> B
A --> C
A --> D
A --> E
Problems:
High Coupling
Hard Maintenance
Difficult Extension
Solution With Observer
flowchart LR
A[Order Service]
B[Observer 1]
C[Observer 2]
D[Observer 3]
E[Observer 4]
A --> B
A --> C
A --> D
A --> E
Subject notifies all observers.
Observer Architecture
flowchart LR
A[Subject]
B[Observer 1]
C[Observer 2]
D[Observer 3]
A --> B
A --> C
A --> D
Key Components
Subject
Maintains observers.
Observer
Receives notifications.
Concrete Subject
Actual event producer.
Concrete Observer
Actual subscriber.
UML Diagram
classDiagram
class Subject {
+registerObserver()
+removeObserver()
+notifyObservers()
}
class Observer {
+update()
}
Subject --> Observer
Real Example
Weather Monitoring System.
When temperature changes:
Weather Station
↓
Mobile App
↓
Website
↓
Display Screen
All get updated.
Weather Flow
flowchart LR
A[Weather Station]
B[Mobile App]
C[Website]
D[Display Screen]
A --> B
A --> C
A --> D
Step 1: Observer Interface
public interface Observer {
void update(
String message);
}
Step 2: Subject Interface
public interface Subject {
void subscribe(
Observer observer);
void unsubscribe(
Observer observer);
void notifyObservers(
String message);
}
Step 3: Concrete Subject
import java.util.ArrayList;
import java.util.List;
public class NewsPublisher
implements Subject {
private List<Observer> observers =
new ArrayList<>();
@Override
public void subscribe(
Observer observer) {
observers.add(observer);
}
@Override
public void unsubscribe(
Observer observer) {
observers.remove(observer);
}
@Override
public void notifyObservers(
String message) {
for(Observer observer :
observers) {
observer.update(message);
}
}
}
Step 4: Concrete Observer
public class Subscriber
implements Observer {
private String name;
public Subscriber(
String name) {
this.name = name;
}
@Override
public void update(
String message) {
System.out.println(
name +
" received: " +
message);
}
}
Step 5: Client Code
public class ObserverDemo {
public static void main(
String[] args) {
NewsPublisher publisher =
new NewsPublisher();
Observer john =
new Subscriber("John");
Observer mike =
new Subscriber("Mike");
publisher.subscribe(john);
publisher.subscribe(mike);
publisher.notifyObservers(
"Breaking News");
}
}
Output
John received: Breaking News
Mike received: Breaking News
Execution Flow
sequenceDiagram
Publisher->>Observer1: update()
Publisher->>Observer2: update()
Publisher->>Observer3: update()
Banking Example
Transaction Completed Event.
Observers:
Email Service
SMS Service
Audit Service
Fraud Service
Banking Architecture
flowchart LR
A[Transaction Service]
B[Email Service]
C[SMS Service]
D[Audit Service]
E[Fraud Service]
A --> B
A --> C
A --> D
A --> E
Insurance Example
Claim Approved Event.
Observers:
Payment Service
Notification Service
Reporting Service
Insurance Flow
flowchart LR
A[Claim Approved]
B[Payment Service]
C[Notification Service]
D[Reporting Service]
A --> B
A --> C
A --> D
E-Commerce Example
Order Placed Event.
Observers:
Inventory Service
Shipping Service
Email Service
Analytics Service
Order Processing Flow
flowchart LR
A[Order Placed]
B[Inventory Service]
C[Shipping Service]
D[Email Service]
E[Analytics Service]
A --> B
A --> C
A --> D
A --> E
Spring Framework Example
Spring Events use Observer Pattern.
Publisher:
applicationEventPublisher.publishEvent(
new OrderCreatedEvent());
Observer:
@EventListener
public void handleEvent(
OrderCreatedEvent event) {
}
Spring Event Flow
flowchart LR
A[Publisher]
B[Spring Event Bus]
C[Listener 1]
D[Listener 2]
E[Listener 3]
A --> B
B --> C
B --> D
B --> E
Kafka Example
Kafka is a distributed Observer implementation.
Producer:
Order Service
Subscribers:
Inventory Service
Notification Service
Analytics Service
Kafka Architecture
flowchart LR
A[Producer]
B[Kafka Topic]
C[Consumer 1]
D[Consumer 2]
E[Consumer 3]
A --> B
B --> C
B --> D
B --> E
Microservices Event Driven Architecture
flowchart LR
A[Order Service]
B[Event Bus]
C[Inventory]
D[Payment]
E[Shipping]
F[Notification]
A --> B
B --> C
B --> D
B --> E
B --> F
Real Enterprise Examples
Banking
Transaction Events
Fraud Alerts
Payment Notifications
Insurance
Claim Events
Policy Updates
Premium Notifications
Retail
Order Events
Inventory Updates
Shipment Notifications
Social Media
Like Events
Comment Events
Follow Events
Streaming Platforms
New Video Uploaded
Subscriber Notifications
Benefits
✅ Loose Coupling
✅ Event Driven Architecture
✅ Easy To Add Subscribers
✅ Better Scalability
✅ High Maintainability
✅ Supports Real-Time Systems
Limitations
❌ Too Many Observers Can Impact Performance
❌ Debugging Event Chains Can Be Difficult
❌ Event Ordering Challenges
❌ Potential Memory Leaks
When To Use
Use Observer Pattern when:
- Event notifications are needed
- Multiple systems react to one event
- Loose coupling is important
- Real-time updates are required
When Not To Use
Avoid when:
- Only one object reacts
- Communication is simple
- Performance is extremely critical
Observer vs Mediator
| Feature | Observer | Mediator |
|---|---|---|
| Purpose | Notification | Coordination |
| Communication | One-to-Many | Many-to-Many |
| Example | Event Bus | Chat Room |
Observer vs Publish Subscribe
| Feature | Observer | Pub/Sub |
|---|---|---|
| Scope | In Process | Distributed |
| Example | Spring Events | Kafka |
| Coupling | Moderate | Very Loose |
Interview Questions
What is Observer Pattern?
A behavioral pattern where observers receive updates when a subject changes.
Main Components?
Subject
Observer
Concrete Subject
Concrete Observer
Real Java Example?
Observer
Observable
(Legacy Java API)
Spring Example?
ApplicationEventPublisher
@EventListener
Kafka Related?
Kafka implements Observer concepts in distributed systems.
Main Benefit?
Loose coupling between event producers and consumers.
Key Takeaways
- Observer is a Behavioral Design Pattern.
- Implements one-to-many communication.
- Enables event-driven architectures.
- Spring Events are a classic implementation.
- Kafka scales Observer Pattern across microservices.
- Widely used in Banking, Insurance, Retail, and Real-Time Systems.
- One of the most important patterns for modern distributed applications.