Overview
The Notification Service is an event-driven, asynchronous microservice responsible for delivering user notifications triggered by important system events such as: . User signup . User login . Order placement
The service is intentionally decoupled from core business workflows to ensure low latency, scalability, and fault isolation.
Problem Statement
Sending notifications synchronously from core services introduces several issues: . Increased API latency . Tight coupling with external systems (e.g., SMTP servers) . Higher failure impact on critical business operations
A failure in email delivery should not affect user signup, login, or order placement.
This service addresses these issues by handling notifications out of band using an event-driven architecture.
High-Level Architecture [ User / Order Service ] | | (Domain Events) v [ Kafka Topic ] | | (Consumer Group) v [ Notification Service ] | v [ Google SMTP ]
How It Works
1: Core services publish domain events (e.g., UserSignedUp, UserLoggedIn, OrderPlaced) to Kafka. 2: The Notification Service consumes events asynchronously using a Kafka consumer group. 3: Events are transformed into notification messages. 4: Notifications are delivered via email using Google SMTP.
This ensures: . Core services remain fast and resilient . Notification failures do not impact business transactions . Notification processing scales independently of business services
Why Kafka?
Kafka is used to: . Decouple producers from consumers . Provide durable and reliable event storage . Enable retries without data loss . Support horizontal scaling via consumer groups
Reliability & Failure Handling
. Messages are acknowledged only after successful notification delivery . SMTP failures are retried using exponential backoff . Duplicate events are handled via idempotent processing . The system remains resilient during temporary downstream outages
Technology Stack
. Java . Spring Boot . Apache Kafka . Google SMTP . Maven
Scalability Considerations
. Consumers scale horizontally using Kafka consumer groups . Notification processing is stateless . High-volume events do not block core business workflows
Future Improvements
. Support for additional channels (SMS, Push Notifications) . Dead Letter Queue (DLQ) for permanently failed messages . Notification templates and localization . Rate limiting per user . Observability (metrics, tracing)
Key Takeaway
This service demonstrates how event-driven architecture can be used to build scalable and fault-tolerant systems by isolating non-critical workflows from core business logic.