Notification Flow in Microservices

 In a microservices architecture, services are decoupled. So if you want to notify a user about an event (like "order processed"), you usually use an asynchronous messaging system rather than calling services directly.

Flow Overview

1. Event happens in a microservice
   Example: OrderService processes an order.

   var orderProcessedEvent = new OrderProcessedEvent { OrderId = 123, UserId = 456 };
   

2. Publish Event to Message Broker

   • Microservice publishes the event to Azure Service Bus topic/queue.

   • Topics allow multiple subscribers, queues deliver to one consumer.

3. Notification Service Subscribes

   • A dedicated Notification Microservice subscribes to the topic/queue.

   • When a message arrives, it triggers notification logic (email, SMS, push).

4. Send Notification to Users

   • Notification Service decides which users should get notified.

   • It uses user preferences/configurations stored in a database.

5. Delivery

   • Email: via SMTP, SendGrid, or Azure Communication Services.

   • Push: via Firebase or Azure Notification Hub.

   • SMS: via Twilio, Azure Communication Services, etc.

---

2. Azure Service Bus Setup

• Queues: point-to-point (one consumer).

• Topics & Subscriptions: publish-subscribe pattern (multiple consumers can get the same event).

Example:

• OrderProcessedTopic

  • Subscription 1 → NotificationService

  • Subscription 2 → AnalyticsService

// Publishing
var client = new ServiceBusClient(connectionString);
var sender = client.CreateSender("OrderProcessedTopic");
await sender.SendMessageAsync(new ServiceBusMessage(JsonSerializer.Serialize(orderProcessedEvent)));

// Subscribing in Notification Service
var processor = client.CreateProcessor("OrderProcessedTopic", "NotificationSubscription");
processor.ProcessMessageAsync += async args => {
    var body = args.Message.Body.ToString();
    var orderEvent = JsonSerializer.Deserialize<OrderProcessedEvent>(body);

    // Send notification logic
    await SendEmailNotification(orderEvent.UserId, "Order Processed");
};

---

3. Email Notification Service

Components:

1. Email Templates – HTML/Plain text templates.

2. SMTP/Email Provider Configuration – SMTP settings (host, port, username, password) or a service like SendGrid/Azure Communication Services.

3. Email Sending Logic – Called by the Notification Service when a message is received.

Sample code using SMTP:

public async Task SendEmailNotification(int userId, string message)
{
    var user = await dbContext.Users.FindAsync(userId);
    if (user == null || string.IsNullOrEmpty(user.Email)) return;

    var smtp = new SmtpClient("smtp.yourmail.com")
    {
        Port = 587,
        Credentials = new NetworkCredential("username", "password"),
        EnableSsl = true,
    };

    var mail = new MailMessage("noreply@yourapp.com", user.Email, "Order Update", message);
    await smtp.SendMailAsync(mail);
}

---

4. Configuring Users for Notifications

1. User Preferences Table

   • Table: UserNotifications

   • Columns: UserId, NotificationType, IsEnabled, Email, PushToken, PhoneNumber

   UserId | NotificationType | IsEnabled | Email           | PushToken | PhoneNumber
   456    | OrderProcessed   | 1         | user@example.com | xyz       | 9999999999
   

2. Check Before Sending

   • Before sending, check if the user wants that type of notification:

   var config = dbContext.UserNotifications
                 .Where(u => u.UserId == userId && u.NotificationType == "OrderProcessed" && u.IsEnabled)
                 .FirstOrDefault();
   if(config != null) SendEmail(...);
   

3. Optional UI – Let users manage preferences in Settings → Notification Preferences.

---

5. Overall Flow Diagram

[OrderService] --(event)--> [Azure Service Bus Topic] --> [NotificationService]
                                                        |--> Email/SMS/Push
                                                        |--> Uses User Preferences from DB

✅ Key Points:

• Use Service Bus for decoupling services.

• Use Notification Service as a central microservice.

• Use user preferences to decide who gets notified.

• Email provider can be SMTP, SendGrid, or Azure Communication Services.

• Optional: extend for SMS, push notifications, or mobile apps.

Background Service in Micro Services - Complete Guide

 A background service that monitors a database for changes (like new orders) and then acts on them. I’ll explain the flow step by step, typical in a .NET Core + Web API + SQL Server environment.

1. What is a Background Service?

In .NET Core, a background service is a long-running process that executes independently of HTTP requests. It can continuously run in the background and perform tasks like:

• Polling a database

• Sending emails or notifications

• Processing queues or orders

In .NET Core, we usually implement it using IHostedService or BackgroundService.

---

2. High-Level Flow for Database Polling

Imagine your scenario: the service checks for new orders and processes them.

1. Database

   • Table: Orders

   • Columns: OrderId, CustomerId, Status, CreatedAt, etc.

   • New orders are inserted with Status = 'Pending'.

2. Background Service (C#)

   • Runs continuously in the background.

   • Periodically checks the Orders table for Status = 'Pending'.

   • Picks up pending orders and updates them to Processing or triggers other actions.

3. Processing Flow

   • Fetch orders:

     var pendingOrders = dbContext.Orders
                         .Where(o => o.Status == "Pending")
                         .ToList();
     

   • Process orders (e.g., send to shipping service, generate invoice, etc.)

   • Update status:

     order.Status = "Processed";
     dbContext.SaveChanges();
     

4. Notification (Optional)

   • Once processed, the service can send notifications via email, push notifications, or enqueue messages in a message broker like Azure Service Bus.

---

3. Sample Flow Diagram

Angular / Frontend
      |
      | [Customer places order]
      v
SQL Server (Orders Table)
      |
      | [Background Service polls DB periodically]
      v
.NET Core Background Service
      |
      |-- Fetch pending orders
      |-- Process orders
      |-- Update status
      |-- Send notifications (optional)
      v
External services / APIs / Notifications

---

4. Polling vs Event-Driven Approach

• Polling:
  The background service queries the database every N seconds/minutes. Simple but less efficient for large-scale systems.

• Event-driven:
  Instead of polling, use a message broker (Azure Service Bus, RabbitMQ, Kafka).

  • Orders insert triggers a message.

  • Background service subscribes and processes only when a new order arrives.

  • More scalable and real-time.

---

5. Example: Implementing BackgroundService in .NET Core

public class OrderProcessingService : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;

    public OrderProcessingService(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            using var scope = _scopeFactory.CreateScope();
            var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();

            var pendingOrders = await dbContext.Orders
                                    .Where(o => o.Status == "Pending")
                                    .ToListAsync();

            foreach (var order in pendingOrders)
            {
                // Process order
                order.Status = "Processed";
            }

            await dbContext.SaveChangesAsync();

            // Wait for some time before next check
            await Task.Delay(TimeSpan.FromSeconds(10), stoppingToken);
        }
    }
}

---

✅ Summary of the Flow:

1. Frontend inserts an order into SQL Server.

2. Background service wakes up periodically.

3. It queries the database for pending orders.

4. Processes each order.

5. Updates the order status.

6. Optional: sends notifications or triggers other services.

7. Repeats indefinitely.