Showing posts with label .net core. Show all posts
Showing posts with label .net core. Show all posts

Thursday, October 9, 2025

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.

Thursday, September 25, 2025

🔹 .NET Framework vs .NET Core

 1. Introduction

  • .NET Framework

    • Released in 2002 by Microsoft.

    • Runs only on Windows.

    • Used for building desktop apps (WinForms, WPF), ASP.NET Web Forms/MVC, enterprise solutions, etc.

    • Mature and widely used, but Windows-only and no active feature development (only security fixes now).

  • .NET Core

    • Released in 2016 as a cross-platform, open-source re-implementation of .NET.

    • Runs on Windows, Linux, macOS.

    • Supports modern development (cloud, microservices, Docker, Kubernetes).

    • Actively developed and evolved into .NET 5+ (Unified .NET platform).


2. Key Differences

Feature.NET Framework.NET Core
Platform SupportWindows-onlyCross-platform (Windows, Linux, macOS)
DeploymentInstalled on Windows systemSelf-contained (bundled with app) or framework-dependent
PerformanceGood, but older runtimeHigh performance, optimized runtime (Kestrel web server)
Open SourceMostly closed sourceFully open source (on GitHub)
Application TypesWinForms, WPF, ASP.NET Web Forms/MVC, WCFASP.NET Core (MVC, Razor Pages, Blazor), Console, Microservices
Cross-Platform Development❌ No✅ Yes
Microservices SupportLimitedExcellent (Docker + Kubernetes ready)
Cloud Support (Azure, AWS)Supported but heavierOptimized for cloud-native
FutureMaintenance only (no major new features)Active development (merged into .NET 5, .NET 6, .NET 7, .NET 8, .NET 9 …)

3. Architecture Differences

.NET Framework:

  • Runs only with Windows OS + IIS (Internet Information Services) for hosting web apps.

  • Traditional monolithic applications.

.NET Core:

  • Uses Kestrel Web Server (lightweight, cross-platform).

  • Can be hosted in IIS, Nginx, Apache, or Docker containers.

  • Supports microservices architecture.


4. Performance

  • .NET Core apps are generally faster because of:

    • JIT (RyuJIT improvements)

    • Lightweight runtime

    • Optimized memory management

    • Kestrel (high-performance web server)

Example: ASP.NET Core can handle millions of requests/sec, while classic ASP.NET Framework is slower.


5. Deployment

  • .NET Framework: Installed on Windows; app depends on that system installation.

  • .NET Core:

    • Framework-dependent deployment (FDD): App runs on shared runtime.

    • Self-contained deployment (SCD): App carries its own runtime — no need to install .NET separately.


6. Ecosystem & Future

  • .NET Framework → Legacy projects, Windows desktop apps (still relevant for enterprises).

  • .NET Core → Foundation for modern apps.

  • In 2020, Microsoft merged everything into a unified platform called .NET 5+ (now we are at .NET 9).

    • .NET Framework will never get new features.

    • .NET Core is the future path.


7. When to Use

  • ✅ Use .NET Framework if:

    • You are maintaining an existing Windows-only enterprise app.

    • You need technologies not yet available in .NET Core (like full WCF or Web Forms).

  • ✅ Use .NET Core / .NET 5+ if:

    • You’re building new applications (web, microservices, cloud-native).

    • You want cross-platform support.

    • You care about performance and scalability.

    • You plan to use Docker, Kubernetes, or cloud hosting.


🔑 Quick Summary

  • .NET Framework = Old, Windows-only, legacy support.

  • .NET Core = Modern, cross-platform, high-performance, future-ready (part of .NET 5+).



Monday, September 15, 2025

🚀 Azure Cloud Services Benefits – A Complete Guide for Modern Applications

Cloud adoption has become the backbone of modern businesses, and Microsoft Azure stands out as one of the most powerful cloud platforms. Whether you’re building a simple website or a complex enterprise-grade microservices application, Azure provides everything from identity management to DevOps-ready container orchestration.

In this article, let’s explore how Azure works step by step, its benefits, and how you can use it with .NET Core backend + Angular frontend applications.


🔑 1. User Creation, Groups & Permissions (Azure Active Directory)

Every cloud journey starts with identity and access management. In Azure, this is handled by Azure Active Directory (Azure AD).

✅ How It Works

  • User Creation: Admins can create users in Azure AD (manual entry, bulk import, or synced from on-premises AD).

  • Groups: Users can be organized into groups (e.g., Developers, Testers, Admins).

  • Permissions (Role-Based Access Control - RBAC): Instead of assigning permissions to individuals, you assign them to groups or roles (e.g., Contributor, Reader, Owner).

  • Single Sign-On (SSO): One login can access Azure Portal, Microsoft 365, and custom business apps.

👉 Example:

  • A developer group can get “Contributor” rights to deploy apps.

  • A tester group can get “Reader” rights to monitor apps but not make changes.

This ensures security, compliance, and streamlined management.


🌐 2. Hosting in Azure (Web Apps & App Services)

Azure makes application hosting simple and scalable with Azure App Services.

✅ Benefits

  • Host .NET Core APIs and Angular UI with minimal configuration.

  • Automatic scaling (based on traffic).

  • Continuous Deployment from GitHub, Azure DevOps, or local machine.

  • Built-in monitoring and logging.

👉 Example:

  • Host your .NET Core Web API in one App Service.

  • Deploy your Angular UI as a Static Web App or in the same App Service.


🐳 3. Containers with Docker

For teams adopting DevOps and portability, Docker on Azure is a game-changer.

✅ How It Works

  • Docker Images: Package your app (.NET API + Angular frontend) into lightweight containers.

  • Azure Container Registry (ACR): Store your private Docker images.

  • Azure App Service for Containers: Run Docker containers directly without managing infrastructure.

👉 Example:
Instead of worrying about server OS and dependencies, you just push your Docker image to ACR and run it.


☸️ 4. Kubernetes with Azure Kubernetes Service (AKS)

When applications grow and need scalability, high availability, and microservices, AKS (Azure Kubernetes Service) is the right choice.

✅ Benefits

  • Automates container orchestration (deployment, scaling, self-healing).

  • Load balances traffic between microservices.

  • Integrates with Azure Monitor and Azure DevOps for CI/CD.

  • Secure communication with Azure AD + RBAC.

👉 Example:
Your .NET Core APIs (User Service, Order Service, Payment Service) run as separate containers. Angular frontend consumes these APIs. Kubernetes ensures uptime even if one container crashes.


📩 5. Messaging with Azure Service Bus

Modern apps often need asynchronous communication between services. That’s where Azure Service Bus helps.

✅ Benefits

  • Decouples microservices with queues and topics.

  • Reliable delivery of messages, even during downtime.

  • Supports FIFO (First-In-First-Out) and pub/sub messaging.

👉 Example:

  • When a user places an order, the Order Service publishes a message to Service Bus.

  • Payment Service and Inventory Service consume the message independently.

This makes your app more resilient and scalable.


🧩 6. Microservices Architecture in Azure

Azure supports building microservices-based applications using:

  • AKS (Kubernetes) for orchestration.

  • Azure Service Bus for communication.

  • Azure API Management for unified API gateway.

  • Cosmos DB / SQL Server for data storage.

👉 Example Setup:

  • Authentication Service – Validates users via Azure AD.

  • Order Service – Handles order logic.

  • Payment Service – Processes payments.

  • Notification Service – Sends email/SMS updates.

Each service runs independently in containers, communicates via Service Bus, and scales individually.


💻 7. .NET + Angular on Azure

One of the most common enterprise stacks is .NET Core backend + Angular frontend, and Azure provides full support.

✅ Typical Workflow

  1. Develop your .NET Core Web APIs.

  2. Build your Angular UI.

  3. Containerize both apps with Docker.

  4. Push images to Azure Container Registry.

  5. Deploy via AKS (Kubernetes) or App Services.

  6. Secure with Azure AD authentication.

  7. Use Azure DevOps CI/CD pipelines for automated builds & deployments.

👉 Example CI/CD Flow:

  • Code pushed to GitHub → Azure DevOps pipeline builds Docker images → Images stored in ACR → AKS auto-deploys latest containers → Angular app fetches API data.


🎯 Final Thoughts

Azure Cloud Services provide end-to-end solutions for hosting, security, scalability, and modern app development. Whether you’re a startup building a simple web app or an enterprise handling millions of transactions, Azure gives you:

  • Identity & Security with Azure AD

  • Reliable Hosting with App Services

  • Portability with Docker

  • Scalability with Kubernetes

  • Asynchronous Messaging with Service Bus

  • Modern Architecture with Microservices

  • Seamless Development with .NET + Angular + DevOps

If you’re moving your apps to the cloud, Azure is not just an option – it’s a complete ecosystem for growth and innovation. 🚀



Saturday, August 30, 2025

How to Implement MicroServices in .Net Core Application- Point-to-point to explanation

 

1) Service boundaries & contracts

  • One business capability per service (e.g., Orders, Payments, Catalog). Each owns its own database.
  • API surface: REST (JSON) or gRPC for synchronous calls; events (Kafka/RabbitMQ/Azure Service Bus) for async integration.
  • Version your APIs (e.g., /v1), keep backward compatible changes, use OpenAPI/Swagger and contract tests (Pact).

2) Resilience patterns (timeouts, retries, circuit breaker, bulkhead)

Use HttpClientFactory + Polly on every outbound call:

builder.Services.AddHttpClient("CatalogClient", c =>

{

    c.BaseAddress = new Uri(config["CatalogUrl"]);

    c.Timeout = TimeSpan.FromSeconds(3);

})

.AddTransientHttpErrorPolicy(p => p.WaitAndRetryAsync(

    retryCount: 3,

    sleepDurationProvider: attempt => TimeSpan.FromMilliseconds(200 * Math.Pow(2, attempt)), // expo backoff

    onRetry: (outcome, ts, attempt, ctx) =>

        logger.LogWarning(outcome.Exception, "Retry {Attempt}", attempt)))

.AddTransientHttpErrorPolicy(p => p.CircuitBreakerAsync(

    handledEventsAllowedBeforeBreaking: 5,

    durationOfBreak: TimeSpan.FromSeconds(30)))

.AddPolicyHandler(Policy.BulkheadAsync<HttpResponseMessage>(maxParallelization: 50, maxQueuingActions: 100));

Rules of thumb

  • Always set timeouts on I/O.
  • Prefer idempotent operations; send Idempotency-Key headers for POSTs where possible.
  • Use cancellation tokens end-to-end.

3) Circuit breaker semantics

  • Trip when a dependency is unhealthy; fail fast and return a cached/partial response or friendly error.
  • Expose breaker state via metrics and health checks (see §5).

4) Data & database handling (consistency without distributed transactions)

  • Database per service (EF Core or Dapper). No cross-service joins.
  • Propagate data between services using domain events—not shared tables.
  • Ensure atomicity with the Outbox pattern:
    1. Write your entity and an OutboxMessage row in the same DB transaction.
    2. A background Outbox Publisher reads unpublished rows and emits them to the broker, then marks them sent.

// Inside your OrderService command handler

await using var tx = db.Database.BeginTransactionAsync();

db.Orders.Add(order);

db.Outbox.Add(new OutboxMessage {

    Type = "OrderPlaced",

    Payload = JsonSerializer.Serialize(new { order.Id, order.Total, order.CustomerId }),

    OccurredOn = DateTimeOffset.UtcNow

});

await db.SaveChangesAsync();

await tx.CommitAsync();

// BackgroundService publisher

protected override async Task ExecuteAsync(CancellationToken ct)

{

    while (!ct.IsCancellationRequested)

    {

        var messages = await db.Outbox

            .Where(m => m.SentOn == null)

            .OrderBy(m => m.OccurredOn)

            .Take(100).ToListAsync(ct);

 

        foreach (var msg in messages)

        {

            await broker.PublishAsync(msg.Type, msg.Payload, ct);

            msg.SentOn = DateTimeOffset.UtcNow;

        }

        await db.SaveChangesAsync(ct);

        await Task.Delay(TimeSpan.FromSeconds(1), ct);

    }

}

  • Updating “relative/related” databases: consume those events in other services to update local read models (CQRS). Use Sagas (orchestration or choreography) for multi-step processes (e.g., Order → Reserve Inventory → Process Payment → Arrange Shipping), with timeouts + compensation.

5) Health checks, readiness, and monitoring

Add liveness (process alive) and readiness (deps OK) endpoints:

builder.Services.AddHealthChecks()

    .AddSqlServer(config.GetConnectionString("OrdersDb"))

    .AddRabbitMQ(config["RabbitMq:Connection"])

    .AddUrlGroup(new Uri(config["CatalogUrl"] + "/health"), name: "catalog");

 

app.MapHealthChecks("/health/live", new HealthCheckOptions { Predicate = _ => false });

app.MapHealthChecks("/health/ready", new HealthCheckOptions {

    Predicate = _ => true,

    ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse

});

  • Kubernetes/Containers probe /health/live and gate traffic on /health/ready.
  • Add self-diagnostics (thread pool starvation, GC info) via EventCounters exported by OpenTelemetry.

6) Observability (logs, traces, metrics)

Unified, structured telemetry makes bugs easy to fix.

OpenTelemetry (logs + traces + metrics) → backends like Grafana Tempo/Prometheus/Loki, Jaeger, Elastic, or Azure Application Insights.

builder.Services.AddOpenTelemetry()

 .WithTracing(t => t

     .AddAspNetCoreInstrumentation()

     .AddHttpClientInstrumentation()

     .AddSqlClientInstrumentation()

     .AddSource("OrderService")

     .AddOtlpExporter()) // or Azure Monitor exporter

 .WithMetrics(m => m

     .AddAspNetCoreInstrumentation()

     .AddRuntimeInstrumentation()

     .AddHttpClientInstrumentation()

     .AddPrometheusExporter());

 

app.MapPrometheusScrapingEndpoint(); // /metrics

Structured logging (e.g., Serilog → console/JSON + sink of choice):

Log.Logger = new LoggerConfiguration()

    .Enrich.FromLogContext()

    .Enrich.WithCorrelationId()

    .WriteTo.Console(new JsonFormatter())

    .WriteTo.Seq(config["SeqUrl"]) // or Elastic/Azure

    .CreateLogger();

 

builder.Host.UseSerilog();

  • Include CorrelationId/TraceId in every log; propagate with middleware:

app.Use(async (ctx, next) =>

{

    var cid = ctx.Request.Headers["X-Correlation-ID"].FirstOrDefault() ?? Guid.NewGuid().ToString();

    ctx.Items["CorrelationId"] = cid;

    ctx.Response.Headers["X-Correlation-ID"] = cid;

    using (LogContext.PushProperty("CorrelationId", cid))

        await next();

});

  • Emit domain events and key business metrics (orders placed, failures, latencies, queue depth).

7) API gateway / proxy servers

  • Use a Gateway for routing, TLS, auth/ratelimiting, request shaping:
    • YARP (in-process .NET reverse proxy) or Ocelot; at the edge you can also use NGINX/Envoy.
  • Centralize AuthN/Z (OAuth2/OIDC via Azure AD, Auth0, or Duende IdentityServer), rate limits, request/response size limits, CORS, and header normalization at the gateway.
  • Prefer service discovery (K8s DNS) and mTLS in cluster; consider a service mesh (Istio/Linkerd) for uniform retries/mtls/traffic shifting and better telemetry without code changes.

8) Security & configuration

  • Never share DBs across services. Grant least privilege per service.
  • Secrets via Azure Key Vault / K8s secrets; bind with IOptions<T> and validate on startup.
  • Enforce TLS everywhere, JWT validation, rotating keys, and input validation (FluentValidation).

9) Deployment & runtime

  • Containerize each service (Docker), build once, promote the same image through Dev → QA → Prod.
  • Orchestrate with Kubernetes (AKS) or Azure App Services for simpler cases.
  • Blue/Green or Canary deployments; mesh/gateway can split traffic gradually.
  • Horizontal scaling via HPA (CPU/RPS/latency). Keep services stateless; externalize state (DB/cache).
  • Caching: local memory for tiny TTLs, Redis for shared cache; always set cache keys + expirations.

10) CI/CD and quality gates

  • GitHub Actions / Azure DevOps Pipelines:
    • Build → unit/integration/contract tests → SCA & SAST → container scan → publish image → deploy via Helm/Bicep/Terraform.
    • Block merges without green tests and security checks.
  • Spin ephemeral test environments per PR when feasible.

11) Diagnostics & “easy bug fixing”

  • Global exception handler → consistent error envelopes with traceId:

app.UseExceptionHandler(builder =>

{

    builder.Run(async ctx =>

    {

        var traceId = Activity.Current?.Id ?? ctx.TraceIdentifier;

        var problem = new { traceId, message = "Unexpected error." };

        ctx.Response.StatusCode = 500;

        await ctx.Response.WriteAsJsonAsync(problem);

    });

});

  • Feature flags (Azure App Configuration) for safe rollouts; dark-launch code paths.
  • Replayable messages (don’t auto-ack until processed). Keep dead-letter queues and dashboards.
  • Synthetic checks (probes that place a tiny test order in lower envs and alert on end-to-end failure).

12) Database migrations & uptime

  • Apply EF Core migrations at startup (carefully) or via migration jobs;
    • Prefer expand-and-contract: add new columns/tables (expand), release code that writes both, backfill, then remove old fields (contract).
  • For read models, permit rebuild from event streams or upstream APIs if corrupted.

13) Monitoring & alerts you’ll actually use

  • Golden signals per service: Latency, Traffic, Errors, Saturation.
  • Alert on SLIs/SLOs (e.g., p95 < 300ms, error rate < 1%), queue lag, breaker open rate, DB CPU, connection pool exhaustion.
  • Route alerts to Teams/Slack with runbooks linked (how to diagnose/rollback).

14) Local/dev ergonomics

  • Docker-compose for local broker + DB + dependencies.
  • Seed data + test fixtures; make services start with sensible defaults.
  • Makefile/PS scripts for common tasks; one-command bootstrap.

Minimal reference architecture (quick checklist)

  • ASP.NET Core services (+ gRPC if needed)
  • HttpClientFactory + Polly (timeouts/retries/circuit breaker/bulkhead)
  • Outbox + BackgroundPublisher; events over Kafka/RabbitMQ/Azure Service Bus
  • DB per service (EF Core/Dapper) + migrations (expand/contract)
  • OpenTelemetry (traces/metrics/logs) → Prometheus/Grafana/Tempo or App Insights
  • Serilog structured logging + correlation IDs
  • Health checks: /health/live, /health/ready
  • API Gateway: YARP/Ocelot; edge NGINX/Envoy; OAuth2/OIDC
  • Containerized; AKS/App Service; blue/green or canary
  • CI/CD with tests, scans, infrastructure as code
  • Feature flags; DLQs; synthetic probes; runbooks


 

Blog Archive

Don't Copy

Protected by Copyscape Online Plagiarism Checker

Pages