A creational design pattern called the Singleton pattern guarantees that a class has a single instance for the duration of the program and that it can be accessed from any location.

We frequently come across situations during software development where having numerous instances of a class could result in issues like inconsistent state or data, resource conflicts, or ineffective resource use. By guaranteeing that a class has a single instance that will be used globally across a program, the singleton pattern resolves this issue.

Prerequisites

• Visual Studio 2022 installed,
• Basics of .NET Core

When Should We Use the Singleton Pattern?
Logging Systems
In most applications, logging should be handled by a single logger instance.

Using a singleton logger ensures:

• All log messages go to the same place (file, database, or monitoring system)
• Logs are written in a consistent format
• No conflicts occur due to multiple logger instances

This makes debugging and monitoring much easier.

Configuration Manager
Application configuration such as connection strings, API keys, or feature flags should be loaded once and shared across the application.

A singleton configuration manager:

• Loads settings a single time
• Provides fast, global access to configuration values
• Ensures consistency across different modules

This avoids repeated file or database reads and improves performance.

Database Connections
Using a singleton for managing database access will:

• Prevents creating multiple unnecessary connections
• Helps control connection usage
• Centralizes database-related logic

Thread Pools
Thread pools are shared resources that should be managed centrally.

Using a singleton thread pool will:

• Avoids uncontrolled thread creation
• Ensures efficient use of system resources
• Improves application stability and performance

A single and well-managed thread pool is better than multiple competing each others.

When we should avoid Singleton

• Singleton should not be used when:
• You need multiple instances with different states
• The class holds user-specific or request-specific data

You want easy unit testing without tight coupling
In many modern .NET Core applications, Dependency Injection (DI) can be a better alternative.

Building blocks of the Singleton Design Pattern

• Private Parameterless constructor: It prevents creating an instance using new keyword from outside the class.
• Sealed Class: It prevents inheritance and also avoids the polymerphism and overridden behavior.
• Private Static Variable: It holds the single instance of the class and having it private ensures the controlled access as well.
• Public Static Method or Property: This will provide central access point to the instance so that we can ensure only one instance existed.

Practical ways to implement the Singleton Design Pattern in C#
Below are the most common and practical ways to implement the Singleton Design Pattern.

• Simple Singleton (NOT Thread-Safe)
• Thread-Safe Singleton using Lock
• Double-Checked Locking Singleton
• Eager Initialization Singleton
• Lazy Initialization Singleton
• Static Class based Singleton
• Singleton via Dependency Injection

1. Simple Singleton (NOT Thread-Safe)
This version of the Singleton pattern is very easy to understand, making it ideal for learning and demonstrations. Its simple structure clearly shows how a single instance is created and reused, and it works correctly in single-threaded applications such as basic console programs.

However, it is not thread-safe. In multi-threaded environments, multiple threads may create more than one instance at the same time, which breaks the Singleton rule. Because of this, it should be used only for learning purposes or simple single-threaded tools, and not in production systems.

Add a AppConfigSingleton.cs file
namespace SingletonPatternInCSharp.Simple
{
    /// <summary>
    /// Basic singleton implementation - NOT thread-safe!
    /// Demonstrates the simplest form of singleton pattern.
    /// </summary>
    public class AppConfigSingleton
    {
        private static AppConfigSingleton? _instance;

        // Private constructor
        private AppConfigSingleton()
        {
            ApplicationName = "Singleton Demo App";
            Version = "1.0.0";
        }

        public static AppConfigSingleton Instance
        {
            get
            {
                if (_instance == null)
                {
                    _instance = new AppConfigSingleton();
                }

                return _instance;
            }
        }

        public string ApplicationName { get; }
        public string Version { get; }
    }
}

Now access it from program.cs as
using SingletonPatternInCSharp.Simple;

var config1 = AppConfigSingleton.Instance;
var config2 = AppConfigSingleton.Instance;

Console.WriteLine($"App: {config1.ApplicationName}");
Console.WriteLine($"Version: {config1.Version}");

// Both references point to the same instance
Console.WriteLine(ReferenceEquals(config1, config2)); // True

2. Thread-Safe Singleton using Lock
This ensures that only one instance of the class is created, even when multiple threads try to access it at the same time. This approach is thread-safe and straightforward to implement, making it suitable for scenarios where multiple threads might try to create the instance simultaneously.

However, there is a performance cost because the lock is applied every time the instance is accessed, even after the Singleton has been created. Despite this, it works well for small-scale multi-threaded applications where the performance overhead is negligible, providing a simple and reliable way to maintain a single shared instance.

Add a LoggerSingleton.cs file
namespace SingletonPatternInCSharp.Thread_Safe_using_Lock
{
    public class LoggerSingleton
    {
        private static LoggerSingleton? _instance;
        private static readonly object _lock = new object();

        // Private constructor prevents external instantiation
        private LoggerSingleton() { }

        public static LoggerSingleton Instance
        {
            get
            {
                lock (_lock)
                {
                    if (_instance == null)
                    {
                        _instance = new LoggerSingleton();
                    }
                    return _instance;
                }
            }
        }

        // Example method for logging
        public void Log(string message)
        {
            Console.WriteLine($"[{DateTime.Now:HH:mm:ss}] {message}");
        }
    }
}

Now access it from program.cs as
// Simulate multiple threads logging at the same time
Parallel.For(0, 5, i =>
{
    var logger = LoggerSingleton.Instance;
    logger.Log($"Message from task {i}");
});

// Verify single instance
var logger1 = LoggerSingleton.Instance;
var logger2 = LoggerSingleton.Instance;
Console.WriteLine(ReferenceEquals(logger1, logger2)); // True

3. Double-Checked Locking Singleton
This is a thread-safe implementation that minimizes the performance overhead of locking. It checks whether the instance already exists before acquiring the lock, and again inside the lock if necessary. This ensures that the lock is applied only once, when the Singleton is first created, making it highly efficient for systems where the instance is accessed frequently.

However, this approach is slightly more complex than a simple locked Singleton and must be implemented carefully to avoid subtle threading issues. It is best suited for high-performance systems where a Singleton is accessed often, providing a balance between thread safety and runtime efficiency.

Add DatabaseManagerSingleton.cs
namespace SingletonPatternInCSharp.Double_Checked_Locking
{
    public class DatabaseManagerSingleton
    {
        private static DatabaseManagerSingleton? _instance;
        private static readonly object _lock = new object();

        // Private constructor prevents external instantiation
        private DatabaseManagerSingleton()
        {
            // Simulate opening a database connection
            Console.WriteLine("Database connection initialized.");
        }

        public static DatabaseManagerSingleton Instance
        {
            get
            {
                // First check without locking (performance optimization)
                if (_instance == null)
                {
                    lock (_lock)
                    {
                        // Double-check inside the lock
                        if (_instance == null)
                        {
                            _instance = new DatabaseManagerSingleton();
                        }
                    }
                }

                return _instance;
            }
        }

        // Example method to simulate database query
        public void ExecuteQuery(string query)
        {
            Console.WriteLine($"Executing query: {query}");
        }
    }
}

Now access it from program.cs as:
// Simulate multiple threads accessing the database manager
Parallel.For(0, 5, i =>
{
    var dbManager = DatabaseManagerSingleton.Instance;
    dbManager.ExecuteQuery($"SELECT * FROM Users WHERE Id = {i}");
});

// Verify single instance
var db1 = DatabaseManagerSingleton.Instance;
var db2 = DatabaseManagerSingleton.Instance;
Console.WriteLine(ReferenceEquals(db1, db2)); // True

4. Eager Initialization Singleton
The Eager Initialization Singleton creates the single instance of the class as soon as the application starts, rather than waiting until it is first needed. This approach is thread-safe by default because the instance is created before any threads can access it, and the implementation is very simple and clean, making it easy to understand and use.

The main drawback is that the instance is created even if it is never used, which could be wasteful for heavy objects. This pattern is best suited for situations where the Singleton is lightweight and the application always requires the instance, ensuring it is available immediately when needed.

Add AppSettingsSingleton.cs
namespace SingletonPatternInCSharp.Eager_Initialization
{
    public class AppSettingsSingleton
    {
        // Eagerly created instance (thread-safe by default)
        private static readonly AppSettingsSingleton _instance = new AppSettingsSingleton();

        // Private constructor prevents external instantiation
        private AppSettingsSingleton()
        {
            AppName = "Eager Singleton Demo App";
            Version = "1.0.0";
            MaxUsers = 100;
        }

        public static AppSettingsSingleton Instance => _instance;

        // Example configuration properties
        public string AppName { get; }
        public string Version { get; }
        public int MaxUsers { get; }
    }
}

Now, access it from program.cs
var settings1 = AppSettingsSingleton.Instance;
var settings2 = AppSettingsSingleton.Instance;

Console.WriteLine($"App: {settings1.AppName}");
Console.WriteLine($"Version: {settings1.Version}");
Console.WriteLine($"Max Users: {settings1.MaxUsers}");

// Verify both references point to the same instance
Console.WriteLine(ReferenceEquals(settings1, settings2)); // True

5. Lazy Initialization Singleton
The Lazy Initialization Singleton uses the Lazy<T> type to create the instance only when it is first accessed, rather than at application startup. This approach is thread-safe by default, easy to read, and avoids the complexity of manual locking. The internal implementation of Lazy<T> handles synchronization and edge cases, making the code clean, reliable, and less error-prone.

There is a very small performance overhead due to the use of Lazy<T>, but in practice this cost is negligible. Because of its safety, clarity, and maintainability, this pattern is recommended for most production systems, including ASP.NET Core applications, microservices, and enterprise-level software.

Add CacheManagerSingleton.cs
namespace SingletonPatternInCSharp.Lazy_Initialization
{
    public class CacheManagerSingleton
    {
        private static readonly Lazy<CacheManagerSingleton> _instance =
            new Lazy<CacheManagerSingleton>(() => new CacheManagerSingleton());

        // Private constructor
        private CacheManagerSingleton()
        {
            Console.WriteLine("Cache Manager initialized.");
            _cache = new Dictionary<string, string>();
        }

        public static CacheManagerSingleton Instance => _instance.Value;

        private readonly Dictionary<string, string> _cache;

        public void Add(string key, string value)
        {
            _cache[key] = value;
        }

        public string Get(string key)
        {
            return _cache.TryGetValue(key, out var value)
                ? value
                : "Not Found";
        }
    }
}

Access it from program.cs as:
// Cache is NOT created yet
Parallel.For(0, 3, i =>
{
    var cache = CacheManagerSingleton.Instance;
    cache.Add($"key{i}", $"value{i}");
});

var cacheManager = CacheManagerSingleton.Instance;
Console.WriteLine(cacheManager.Get("key1"));

6. Static Class based Singleton
A static class is often used as a Singleton alternative in C#, even though it is not a true implementation of the Singleton pattern. Since static members are initialized by the runtime and exist only once per application domain, this approach is thread-safe by default, has no instantiation issues, and offers very fast access without any additional overhead.

However, static classes come with important limitations. They cannot implement interfaces, do not support inheritance, and offer no control over lazy initialization beyond what the runtime provides. Because of these constraints, static classes are best suited for utility-style functionality, such as configuration values, constants, helper methods, and shared utilities, where simplicity and performance are more important than flexibility or extensibility.

Add DatabaseConnectionProvider.cs
using Microsoft.Data.SqlClient;

namespace SingletonPatternInCSharp.Static_Class
{
    public static class DatabaseConnectionProvider
    {
        private static readonly string _connectionString =
            "Server=localhost;Database=AppDb;Trusted_Connection=True;";

        public static SqlConnection GetConnection()
        {
            return new SqlConnection(_connectionString);
        }
    }
}

Access it from program.cs as:
SqlConnection connection1 = DatabaseConnectionProvider.GetConnection();
SqlConnection connection2 = DatabaseConnectionProvider.GetConnection();

Console.WriteLine(connection1.ConnectionString);
Console.WriteLine(connection2.ConnectionString);

// These are different objects, created by a static provider
Console.WriteLine(ReferenceEquals(connection1, connection2)); // False

7. Singleton via Dependency Injection
The Singleton via Dependency Injection approach relies on the application’s DI container to manage the lifetime of the object instead of implementing the Singleton pattern manually. By registering a service as a singleton, the framework ensures that only one instance is created and shared throughout the application. This results in cleaner code, with no explicit singleton logic, locks, or static access.

This approach is highly testable, as services can be easily mocked or replaced, and the object’s lifecycle is fully managed by the framework. The main drawback is that it requires a DI container, which may not be suitable for very simple applications. It is the preferred approach in ASP.NET Core and modern .NET applications, where maintainability, scalability, and clean architecture are key design goals.

Add ILoggerService.cs
namespace SingletonPatternInCSharp.Dependency_Injection
{
    public interface ILoggerService
    {
        void Log(string message);
    }
}

Add LoggerService.cs
namespace SingletonPatternInCSharp.Dependency_Injection
{
    public class LoggerService : ILoggerService
    {
        public void Log(string message)
        {
            Console.WriteLine($"[{DateTime.Now:HH:mm:ss}] {message}");
        }
    }
}

Access it from program.cs as:
// Create service collection
var services = new ServiceCollection();

// Register LoggerService as Singleton
services.AddSingleton<ILoggerService, LoggerService>();

// Build service provider
var serviceProvider = services.BuildServiceProvider();

// Resolve service multiple times
var singletonLogger1 = serviceProvider.GetRequiredService<ILoggerService>();
var singletonLogger2 = serviceProvider.GetRequiredService<ILoggerService>();

singletonLogger1.Log("First log message");
singletonLogger2.Log("Second log message");

// Verify singleton behavior
Console.WriteLine(ReferenceEquals(singletonLogger1, singletonLogger2)); // True

Cheers !

Consider ASP.NET Core as a high-speed internet request assembly line. Every time a user accesses the website, their request passes through a number of "stations" known as middleware. The software can do specific tasks at each station, such as collecting data, managing issues, or determining whether the user is logged in. If something goes wrong, such as a security guard barring someone without a badge, these stations can even "stop" a request early.

This article will examine middleware, or how ASP.NET Core handles incoming requests.

Middleware: What is it?
The ASP.NET Core request pipeline relies heavily on middleware. It operates as a series of software elements intended to handle both incoming and outgoing HTTP requests. Before a request reaches the application's primary logic, each piece of middleware has the ability to examine, modify, or even halt it. This configuration offers an organized method of handling security, error management, and logging.

A request enters the application and moves through the pipeline in the precise order that each component has been registered. Each middleware component must decide whether to process the request and forward it to the subsequent component or to immediately produce a response.

When a component stops a request from moving further, it "short-circuits" the pipeline a perfect tactic for blocking unauthenticated users or delivering cached content instantly.

The beauty of this pipeline is its total flexibility. We can rely on built-in middleware for common needs like routing and authentication, or develop custom components for specialized tasks. Because these pieces run one after another, their order is vital. For example, authentication must always occur before authorization so the system knows who a user is before deciding what they can access.

Setting up this pipeline is straightforward in the Program.cs file, using simple methods like app.Use, app.Run, and app.Map. This organized approach ensures every request is handled predictably while giving the power to customize the entire journey.

How Middleware Work?
Every piece of middleware in the pipeline follows a consistent pattern- it receives the HttpContext, performs its specific task, and then either passes control to the next component or "short-circuits" the process by sending a response back immediately. When middleware short-circuits a request, it stops all remaining components from running, which is a great way to optimize performance by handling errors or serving cached data early.

By organizing these components correctly, we can efficiently manage security, logging, and data transformations. This structured approach ensures that every request flows through ASP.NET Core application in a smooth, fast, and predictable way.

The order of the middleware is critical. Components run sequentially as requests flow in and responses flow out.

• Request Flow (Inbound): The request goes down the pipeline in the order we have register middleware (Top-Down).
• Response Flow (Outbound): The response travels back up the pipeline in the reverse order (Bottom-Up) if await next() was called.

// Layer 1: The Receptionist (Logging)
app.Use(async (context, next) =>
{
    Console.WriteLine("Receptionist: Checking the visitor in...");
    await next(); // Allow the visitor to go to the next floor
    Console.WriteLine("Receptionist: Checking the visitor out...");
});

// Layer 2: Security Scanner (Authentication)
app.Use(async (context, next) =>
{
    Console.WriteLine("Scanner: Checking ID badge...");

    // Example of short-circuiting:
    // If no ID is found, we stop them here and don't call next()
    if (!context.Request.Headers.ContainsKey("X-ID-Badge"))
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Access Denied: No Badge Found.");
        return;
    }

    await next();
    Console.WriteLine("Scanner: Scanning bags on the way out...");
});

// Layer 3: The Office (The Final Destination)
app.Run(async (context) =>
{
    Console.WriteLine("Office: Doing the actual work...");
    await context.Response.WriteAsync("Welcome to the main office!");
});

Expected Execution Flow:

• Receptionist: Checking the visitor in...
• Scanner: Checking ID badge...
• Office: Doing the actual work...
• Scanner: Scanning bags on the way out...
• Receptionist: Checking the visitor out...

Request Delegate & HttpContext:
Understanding the relationship between the Request Delegate and HttpContext is essential for mastering the ASP.NET Core pipeline.

The HttpContext (The Cargo)

Think of the HttpContext as a large envelope that contains everything about a single web request. It travels through the entire pipeline and carries:

• Request: Information coming in (URL, Headers, Cookies, Form data).
• Response: Information going out (Status code, Body, Headers).
• User: Information about who is making the request.
• The Request Delegate (The Worker)

A Request Delegate is a functional piece of code (specifically a RequestDelegate) that processes the HttpContext. It is the "worker" that looks at the envelope, does something with it, and passes it to the next worker.
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// This function IS a Request Delegate
// It takes HttpContext as an input and returns a Task
RequestDelegate myWorker = async (HttpContext context) =>
{
    // Reading from the HttpContext (The Request)
    string? userAgent = context.Request.Headers.UserAgent;

    // Writing to the HttpContext (The Response)
    context.Response.StatusCode = 200;
    await context.Response.WriteAsync($"Our browser is: {userAgent}");
};

// Telling the app to use our worker for all requests
app.Run(myWorker);

app.Run();

Summary of the Relationship:

• HttpContext is the data (the "what").
• Request Delegate is the logic (the "how").

When a request hits the server, ASP.NET Core creates the HttpContext and hands it to the first Request Delegate in the pipeline.

Built-In Middlewares
ASP.NET Core remains a powerhouse for web development largely due to its robust library of pre-configured Middleware. These built-in components act as ready-made "checkpoints" that we can plug into our request pipeline to handle critical tasks like security, traffic routing, and error management without writing custom code from scratch.

Exception Handling Middleware
Captures unhandled crashes and provides a centralized way to log errors and return custom error responses.
app.UseExceptionHandler("/Error");

Routing Middleware
Analyzes the incoming URL to determine which endpoint (like a Controller or Minimal API) should handle the request.
app.UseRouting();

Authentication and Authorization Middleware
These work together to secure the app: UseAuthentication identifies the user, while UseAuthorization checks their permissions.
app.UseAuthentication();

app.UseAuthorization();

Static Files Middleware
Efficiently serves assets like images, CSS, and JavaScript directly from the wwwroot folder.
app.UseStaticFiles();

CORS Middleware
Cross-Origin Resource Sharing (CORS) manages which external domains are permitted to access the API.
app.UseCors(p => p.WithOrigins("https://trusted.com").AllowAnyMethod());

Response Compression Middleware
Reduces bandwidth usage by shrinking responses before they are sent to the client, improving performance.

app.UseResponseCompression();

Session Middleware
Enables the application to store and retrieve user-specific data during their visit using in-memory or distributed caches.
app.UseSession();

HTTPS Redirection Middleware
Secures communication by automatically forcing all incoming HTTP requests to use the encrypted HTTPS protocol.
app.UseHttpsRedirection();

Request Logging Middleware
Records details about every HTTP request, which is essential for debugging, monitoring, and security audits.
app.UseSerilogRequestLogging();

Endpoint Middleware
The final stage where the request is dispatched to its intended target, such as a Controller or Razor Page.
app.MapControllers();

The order of registration is critical. For example, we must always call UseRouting before UseAuthorization so the app knows which resource is being accessed before checking if the user has permission to see it.

Custom Middleware
This remains one of the most powerful ways to extend our application's capabilities. While the built-in tools cover the basics, creating our own middleware allows us to inject specialized logic—like custom security headers, niche logging, or unique business rules—directly into the heart of the request pipeline. We will look into it more detail in another article, lets focus on in-built ones in this article.

How to create and stop Middleware pipeline
Request Delegate based Middleware remains the most straightforward method for injecting custom logic into the pipeline. This approach uses inline delegates, allowing us to define middleware directly within Program.cs file without the overhead of creating separate classes.

This method is perfect for quick tasks like specialized logging, adding custom headers, or simple performance timing.
// Simple monitoring middleware
app.Use(async (context, next) =>
{
    // Logic before the next component runs
    Console.WriteLine($"Incoming: {context.Request.Method} {context.Request.Path}");

    await next(); // Hand control to the next middleware in line

    // Logic after the rest of the app has finished
    Console.WriteLine($"Outgoing: Status {context.Response.StatusCode}");
});

Short-Circuiting is a vital performance and security tactic in ASP.NET Core. It occurs when a middleware component generates a response and decides not to call the next middleware in the pipeline. This effectively stops the request from traveling any further, preventing unnecessary processing in controllers or database.

In this example, the middleware checks a "Maintenance Mode" flag. If active, it short-circuits the pipeline and tells the user to come back later, protecting the rest of the app during updates.
bool isMaintenanceMode = true;

app.Use(async (context, next) =>
{
    if (isMaintenanceMode)
    {
        // 1. Set the response status
        context.Response.StatusCode = 503; // Service Unavailable

        // 2. Send the message
        await context.Response.WriteAsync("Site is down for maintenance. Please try again later.");

        // 3. IMPORTANT: We do NOT call 'await next()'.
        // This short-circuits the pipeline here.
        return;
    }

    // If not in maintenance, continue as normal
    await next();
});

app.MapGet("/", () => "Welcome to the App!");

Best Practices
Middleware remains a cornerstone for processing traffic in ASP.NET Core Web APIs. Properly designing and organizing the pipeline is essential for ensuring high performance, long-term maintainability, and robust security.

1. Order is Everything
Middleware executes in the exact sequence it is registered in Program.cs. Always place Exception Handling first to catch all downstream errors, followed by Routing, then Authentication, and finally Authorization. Getting this wrong can lead to security holes or unhandled crashes.

2. Keep Middleware "Lean"
Middleware should be fast and focused on a single task (like logging or security). Avoid putting heavy business logic or long-running database queries inside a middleware component. If it takes too long to process, it slows down every single request entering the application.

3. Use Short-Circuiting Wisely
Stop the request as early as possible if it doesn't meet requirements. For example, if an API Key is missing, return a 401 Unauthorized immediately. This prevents the request from hitting expensive resources like database or external services.

4. Avoid "Fat" Program.cs Files
For complex logic, move the middleware into a separate Middleware Class rather than using long inline lambda expressions. This keeps the startup code clean and makes the custom logic much easier to unit test.

5. Use Built-in Middleware First
Before writing a custom solution, check if a built-in component exists. ASP.NET Core provides highly optimized middleware for CORS, Compression, Caching, and Rate Limiting. These are maintained by Microsoft and are typically more performant and secure than custom-built alternatives.

Here is the professional standard for arranging the middleware to ensure every request is handled efficiently:
var app = builder.Build();

// 1. Global Exception Handling - Catch all errors from the very start
app.UseExceptionHandler("/error");

// 2. HTTPS Redirection - Secure the connection before processing data
app.UseHttpsRedirection();

// 3. Routing Middleware - Determine where the request is trying to go
app.UseRouting();

// 4. CORS Middleware - Validate cross-origin access early
app.UseCors();

// 5. Authentication - Identify WHO the user is
app.UseAuthentication();

// 6. Authorization - Confirm WHAT the user can do
app.UseAuthorization();

// 7. Custom Middleware - Niche logic (e.g., specialized logging or headers)
app.UseMiddleware<CustomMiddleware>();

// 8. Endpoint Execution - Finally execute the controller or minimal API logic
app.MapControllers();

app.Run();

Why this specific order is best:
Safety First: Placing Exception Handling at the very top ensures that if any later middleware (like Database or Custom logic) crashes, the error is caught and handled gracefully.
Efficiency: By placing CORS and Authentication before the custom logic, we can reject unauthorized or untrusted requests before the server wastes any time processing them.
Logic Flow: We must call Routing before Authorization because the system needs to know which "room" the user is trying to enter before it can check if they have the specific key for it.

Conclusion
In this article we have seen how Middleware remains the essential foundation of the ASP.NET Core request pipeline, providing a structured way to manage global tasks like security, logging, and error handling. By mastering the way these components function and strictly following the correct execution order, we can ensure Web APIs are built for high performance, maximum security, and long-term maintainability. Hope this helps.

"Stability" in the context of cloud-native development frequently refers to how well your program manages its own demise. Pods on Google Kubernetes Engine (GKE) are continuously updated, resized, or migrated. Users will get the dreaded 503 Service Unavailable errors if your application does not gracefully handle these transitions. We'll examine the SIGTERM signal, its significance for.NET architects, and how to put a graceful shutdown plan in place in this post.

A SIGTERM signal: what is it?
GKE doesn't simply "pull the plug" when it chooses to end a pod, whether because of a rolling update, a scale-down event, or node maintenance. Rather, it adheres to a synchronized order:

• The Signal: The process (PID 1) within your container receives a SIGTERM (Signal Terminate) from Kubernetes.
• The Grace Period: Kubernetes waits for a predetermined amount of time (30 seconds by default).
• The Kill: Kubernetes delivers a SIGKILL, which instantly terminates the application, if the process is still operating beyond the grace period.

The "final boarding call" for your application is the SIGTERM. This is your opportunity to complete current tasks, flush buffers, and cease taking new requests.

Why It's Not a Strategy to "Wait and See"

If the SIGTERM signal is disregarded:

• Dropped Requests: Users will notice a connection reset in the middle of a request.
• Data corruption: Database transactions or file writes may be interrupted in the middle.
• Zombie State: If a consumer passes away in a system like Kafka without committing its offset, the subsequent consumer will reprocess the same messages, creating duplicates.

Realtime web apps are no longer optional they’re expected. Whether it’s live stock prices, monitoring dashboards, or social media alerts, users want to see updates instantly without refreshing the page.

For a long time, Server-Sent Events (SSE) has been a simple and efficient way to send updates from the server to the browser. It’s lighter than WebSockets when you only need one-way communication. But in ASP.NET Core, using SSE usually meant extra work—setting headers manually, writing to the response stream, and handling connection cancellation yourself.

.NET 10 introduces a cleaner and easier way to use SSE in Minimal APIs with TypedResults.ServerSentEvents.

What is TypedResults.ServerSentEvents?
TypedResults.ServerSentEvents is a new feature that lets you return an SSE stream almost as easily as returning JSON. You just return an IAsyncEnumerable<SseItem<T>>, and ASP.NET Core takes care of the rest:

• Sets the correct Content-Type (text/event-stream)
• Formats the data to match the SSE standard
• Manages the connection automatically

This means less code, fewer mistakes, and a much simpler way to build realtime features in .NET 10.

The Code
The source code can be downloaded from GitHub - SSE DEMO and GitHub -SSE Client

Let's build a simple "Stock Ticker" simulation.

1. The Backend (ASP.NET Core)
First, we define our data model and a simple generator function that simulates a stream of stock updates.
using System.Runtime.CompilerServices;
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.UseDefaultFiles();
app.UseStaticFiles();
// The SSE Endpoint
app.MapGet("/stock-stream", () =>
return TypedResults.ServerSentEvents(GetStockUpdates());
});
// The Batched SSE Endpoint (Secured)
app.MapGet("/stock-stream-batch", (HttpContext context) =>
{
// Simple API Key Authentication
if (!context.Request.Headers.TryGetValue("X-API-Key", out var apiKey) || apiKey != "secret-key-123")
{
return Results.Unauthorized();
}
return TypedResults.ServerSentEvents(GetStockUpdatesBatch());
});
app.Run();
// Simulating a data stream
async IAsyncEnumerable<SseItem<List<StockUpdate>>> GetStockUpdates(
[EnumeratorCancellation] CancellationToken ct = default)
{
var random = new Random();
var symbol = "MSFT";
var price = 420.00m;
while (!ct.IsCancellationRequested)
{
var batch = new List<StockUpdate>();
// Create a batch of 3 updates
for(int i = 0; i < 3; i++)
{
price += (decimal)(random.NextDouble() * 2 - 1);
batch.Add(new StockUpdate(symbol, Math.Round(price, 2), DateTime.UtcNow));
}
// Yield an SSE Item containing the list
yield return new SseItem<List<StockUpdate>>(batch, "price-update")
{
EventId = Guid.NewGuid().ToString()
};
await Task.Delay(1000, ct); // Update every second
}
}
// Simulating a batched data stream (bursts of events from DB/Service)
async IAsyncEnumerable<SseItem<StockUpdate>> GetStockUpdatesBatch(
[EnumeratorCancellation] CancellationToken ct = default)
{
var random = new Random();
var symbols = new[] { "MSFT", "GOOG", "AAPL", "NVDA" };
var prices = new Dictionary<string, decimal>
{
["MSFT"] = 420.00m, ["GOOG"] = 175.00m, ["AAPL"] = 180.00m, ["NVDA"] = 950.00m
};
while (!ct.IsCancellationRequested)
{
// Simulate fetching a list of updates from a database or external service
// Randomly simulate "no records found" (e.g., 20% chance)
// Randomly simulate "no records found" (e.g., 20% chance)
if (random.NextDouble() > 0.2)
{
// Step 1: Query Database (e.g. var results = await db.GetUpdatesAsync();)
// We fetch ALL updates in a single query here.
// Step 2: Stream the results one by one
foreach (var symbol in symbols)
{
prices[symbol] += (decimal)(random.NextDouble() * 2 - 1);
var update = new StockUpdate(symbol, Math.Round(prices[symbol], 2), DateTime.UtcNow);
yield return new SseItem<StockUpdate>(update, "price-update")
{
EventId = Guid.NewGuid().ToString()
};
}
}
// If no records found, we simply yield nothing this iteration.
// The connection remains open, and the client waits for the next check.
await Task.Delay(1000, ct); // Update every second
}
}
record StockUpdate(string Symbol, decimal Price, DateTime Timestamp);

2. The Frontend (Vanilla JS)
Consuming the stream is standard SSE. We use the browser's native EventSource API.
<!DOCTYPE html>
<html>
<head>
<title>.NET 10 SSE Demo</title>
</head>
<body>
<h1>Stock Ticker </h1>
<div id="ticker">Waiting for updates...</div>
<script>
const tickerDiv = document.getElementById('ticker');
const eventSource = new EventSource('/stock-stream');
eventSource.addEventListener('price-update', (event) => {
const batch = JSON.parse(event.data);
tickerDiv.innerHTML = '';
batch.forEach(data => {
tickerDiv.innerHTML += `
<div>
<strong>${data.symbol}</strong>: $${data.price}
<small>(${new Date(data.timestamp).toLocaleTimeString()})</small>
</div>
`;
});
});
eventSource.onerror = (err) => {
console.error("EventSource failed:", err);
eventSource.close();
};
</script>
</body>
</html>

3. The C# Client (Hosted Service)
For backend-to-backend communication (like a Hosted Service in IIS), .NET 9+ introduces SseParser.
using System.Net.ServerSentEvents;

using System.Text.Json;

// Connect to the stream

using var client = new HttpClient();

client.DefaultRequestHeaders.Add("X-API-Key", "secret-key-123"); // Add Auth Header

using var stream = await client.GetStreamAsync("http://localhost:5000/stock-stream-batch");

// Parse the stream

var parser = SseParser.Create(stream);

await foreach (var sseItem in parser.EnumerateAsync())

{

if (sseItem.EventType == "price-update")

{

var update = JsonSerializer.Deserialize<StockUpdate>(sseItem.Data, new JsonSerializerOptions

{

PropertyNameCaseInsensitive = true

});

Console.WriteLine($"Received: {update?.Symbol} - ${update?.Price}");

}

}

record StockUpdate(string Symbol, decimal Price, DateTime Timestamp);

Security Considerations
Passing an API Key in a header (like X-API-Key) is a common pattern, but it comes with risks:

• HTTPS is Mandatory: Headers are sent in plain text. If you use HTTP, anyone on the network can sniff the key. Always use HTTPS in production to encrypt the traffic (including headers).
• Key Rotation: Static keys can be leaked. Ensure you have a way to rotate keys without redeploying the application.
• Better Alternatives: For high-security scenarios, consider using OAuth 2.0 / OIDC (Bearer tokens) or mTLS (Mutual TLS) for server-to-server authentication.

Conclusion
Server-Sent Events (SSE) offer a lightweight and efficient standard for handling real-time unidirectional data streams. By leveraging standard HTTP connections, SSE avoids the complexity of WebSockets for scenarios where the client only needs to receive updates. Whether you're building live dashboards, notification systems, or news feeds, SSE provides a robust and easy-to-implement solution that keeps your application responsive and up-to-date. Happy Coding!

Building message-based (asynchronous) applications is made easier with MassTransit, a free and open-source distributed application framework for.NET. You may concentrate on business logic rather than low-level messaging issues since it offers a consistent abstraction over message brokers like RabbitMQ, Azure Service Bus, Amazon SQS, ActiveMQ, and Kafka.

Key Features

• Message-based communication: Enables decoupled systems using publish/subscribe, request/response, and event-driven patterns.
• Transport abstraction: Works with multiple brokers (RabbitMQ, Azure Service Bus, etc.) without changing your application code.
• Saga support: Implements long-running workflows with state machines.
• Middleware pipeline: Similar to ASP.NET Core middleware, lets you plug in logging, retries, and other behaviors.
• Dependency injection friendly: Integrates seamlessly with .NET DI containers.
• Resiliency: Built-in support for retries, fault handling, and message durability.

Example Usage
Here’s a simple example of setting up MassTransit with RabbitMQ:

using MassTransit;
using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection();

services.AddMassTransit(x =>
{
x.AddConsumer<OrderSubmittedConsumer>();

x.UsingRabbitMq((context, cfg) =>
{
    cfg.Host("localhost", "/", h =>
    {
        h.Username("guest");
        h.Password("guest");
    });

    cfg.ConfigureEndpoints(context);
});
});

var provider = services.BuildServiceProvider();
var busControl = provider.GetRequiredService<IBusControl>();

await busControl.StartAsync();

And a consumer
public class OrderSubmittedConsumer : IConsumer<OrderSubmitted>
{
public Task Consume(ConsumeContext<OrderSubmitted> context)
{
    Console.WriteLine($"Order received: {context.Message.OrderId}");
    return Task.CompletedTask;
}
}

Real-World Use Cases

• Microservices communication (publish/subscribe events across services).
• Background processing (offloading heavy tasks to queues).
• Workflow orchestration (using sagas for long-running processes).
• Integration with cloud services (Azure Service Bus, AWS SQS).

Why Use MassTransit?

• It’s lightweight compared to alternatives like NServiceBus.
• It’s open-source and free.
• It reduces boilerplate code for messaging.
• It’s designed for high throughput and scalability.

MassTransit in .NET is a powerful framework for building distributed, event-driven, and message-based applications, abstracting away the complexity of working directly with message brokers while giving you robust tools for scalability and resiliency.

Email is still one of the best platforms for marketing, notifications, and user interaction. But creating emails by hand for every situation is ineffective and frequently doesn't engage users. AI is used in dynamic email creation to produce context-aware, tailored content that improves engagement, increases open rates, and facilitates scalable communication. This paper covers architecture, best practices, and practical implementation patterns for leveraging AI in ASP.NET Core to create a dynamic email generation system that is ready for production.

1. Introduction
Traditional static emails:

• Require manual editing for each campaign
• Cannot adapt content dynamically
• Fail to provide personalized experiences

Dynamic email generation solves this by:

• Creating content automatically based on user behavior, preferences, or context
• Adapting the tone, format, and message to individual recipients
• Using AI to craft content that is grammatically correct, engaging, and relevant

2. Why Dynamic Emails Matter
Dynamic emails improve:

• Engagement: Personalization increases open and click-through rates.
• Scalability: One system can generate thousands of variations automatically.
• Relevance: Tailored content improves customer satisfaction and conversion.

AI-driven emails are particularly effective for:

1. Transactional notifications
2. Marketing campaigns
3. Onboarding sequences
4. Customer support follow-ups

3. Architecture Overview
A production-ready dynamic email system includes:

1. Email Request API: Receives requests for email generation.
2. Template Engine: Holds reusable templates with placeholders.
3. AI Content Engine: Generates or enhances email content dynamically.
4. Email Service: Formats and sends emails.
5. Logging & Monitoring: Tracks delivery, open rates, and errors.

High-Level Flow:
User Action → API Request → AI Content Generation → Template Rendering → Email Sent → Monitoring

4. Technology Stack

• Backend: ASP.NET Core 7
• Frontend / Dashboard: Optional Angular for email previews
• AI Engine: OpenAI API, Azure OpenAI, or custom ML model
• Email Provider: SMTP, SendGrid, Amazon SES, or Mailgun
• Database: SQL Server or PostgreSQL for storing templates, logs, and user preferences
• Logging & Monitoring: Serilog, Application Insights, or ELK Stack

5. Designing the Email Template System
A flexible template system is critical. Templates use placeholders that can be replaced dynamically with user data or AI-generated content.
Example Template:
<!DOCTYPE html>
<html>
<head>
    <title>{{subject}}</title>
</head>
<body>
    <h1>Hello {{firstName}},</h1>
    <p>{{body}}</p>
    <p>Best regards,<br/>{{companyName}}</p>
</body>
</html>

    {{firstName}} and {{companyName}} are static placeholders.

    {{body}} can be generated dynamically by AI.

Template Storage:
Database table with TemplateId, Name, Content, CreatedAt, UpdatedAt
Supports versioning for campaigns and rollback

6. Integrating AI for Content Generation
AI can generate or enhance the body of the email based on context.

Example: Using OpenAI API
public async Task<string> GenerateEmailContent(string context)
{
    var client = new OpenAIClient(new OpenAIClientOptions
    {
        ApiKey = _configuration["OpenAI:ApiKey"]
    });

    var prompt = $"Generate a professional, friendly email about {context}";

    var response = await client.ChatCompletions.CreateAsync(
        new ChatCompletionsOptions
        {
            Messages =
            {
                new ChatMessage(ChatRole.User, prompt)
            },
            MaxTokens = 300
        });

    return response.Choices[0].Message.Content.Trim();
}

Tips for Production:
Limit token usage to control costs
Include context such as user behavior, product info, or previous interactions

Cache AI-generated content if needed for retries

7. Building an ASP.NET Core Email Service
Email Service Interface
public interface IEmailService
{
    Task SendEmailAsync(string to, string subject, string body, string htmlBody = null);
}

Implementation Using SMTP

public class SmtpEmailService : IEmailService
{
    private readonly IConfiguration _config;

    public SmtpEmailService(IConfiguration config)
    {
        _config = config;
    }

    public async Task SendEmailAsync(string to, string subject, string body, string htmlBody = null)
    {
        var message = new MimeMessage();
        message.From.Add(MailboxAddress.Parse(_config["Email:From"]));
        message.To.Add(MailboxAddress.Parse(to));
        message.Subject = subject;

        var builder = new BodyBuilder { TextBody = body, HtmlBody = htmlBody };
        message.Body = builder.ToMessageBody();

        using var client = new SmtpClient();
        await client.ConnectAsync(_config["Email:Smtp:Host"], int.Parse(_config["Email:Smtp:Port"]), true);
        await client.AuthenticateAsync(_config["Email:Smtp:User"], _config["Email:Smtp:Password"]);
        await client.SendAsync(message);
        await client.DisconnectAsync(true);
    }
}

8. Sending Emails via Third-Party Providers
For high-volume production environments, use providers like SendGrid, Amazon SES, or Mailgun:

• Better deliverability
• Retry and bounce handling
• Analytics on open/click rates

Example: SendGrid integration with ASP.NET Core:
var client = new SendGridClient(apiKey);
var msg = new SendGridMessage()
{
    From = new EmailAddress("[email protected]", "Company Name"),
    Subject = subject,
    HtmlContent = htmlBody,
    PlainTextContent = body
};
msg.AddTo(new EmailAddress(to));
await client.SendEmailAsync(msg);

9. Personalization and Dynamic Placeholders
Before sending, replace placeholders with actual values:
public string ReplacePlaceholders(string template, Dictionary<string, string> values)
{
    foreach (var kv in values)
    {
        template = template.Replace($"{{{{{kv.Key}}}}}", kv.Value);
    }
    return template;
}

    Replace {{firstName}}, {{companyName}}, and AI-generated {{body}} dynamically

    Combine static user data with AI content for fully personalized emails

10. Logging and Monitoring Email Delivery
Logging is critical to track:

• Sent emails
• Delivery status
• Bounces and failures

Example: Using Serilog to log email events:
Log.Information("Email sent to {Email} with subject {Subject}", to, subject);

Store logs in database for analytics

Use monitoring dashboards to track open/click rates

11. Security Considerations

• Never expose API keys in frontend code
• Validate email addresses before sending
• Use TLS/SSL for SMTP or provider APIs
• Avoid sensitive information in email body unless encrypted
• Implement rate limiting to avoid abuse

12. Performance and Scalability

• Queue emails using background jobs (Hangfire, Azure Functions, or RabbitMQ)
• Batch sending for large campaigns
• Cache AI-generated content to reduce API calls
• Use async methods in ASP.NET Core to handle high concurrency

13. Conclusion
Dynamic email generation with AI in ASP.NET Core allows developers to:

• Automate email content creation
• Personalize emails at scale
• Integrate AI for context-aware, engaging messages

A production-ready system requires:

• Template management with placeholders
• AI content generation with contextual input
• Secure, scalable email sending via SMTP or third-party providers
• Logging and monitoring for reliability and analytics

Key Takeaways for Senior Developers

• Separate template rendering from AI content generation.
• Use dependency injection for email services in ASP.NET Core.
• Personalize emails combining static user data and AI-generated content.
• Use background processing to scale email sending efficiently.
• Monitor delivery, open rates, and failures for actionable insights.

One of the most potent features of.NET is asynchronous programming, which makes applications run more quickly and remain responsive. Appropriate use of async and await is crucial for optimal performance, whether you're developing a web API, desktop application, mobile application, or background service. Nevertheless, a lot of developers utilize these terms without completely comprehending their functionality, which might result in unanticipated delays, deadlocks, or halted threads. This article covers best practices, provides concise explanations of async and await, demonstrates how they operate in the background, and offers practical examples that you can use to actual.NET applications.

What is.NET Asynchronous Programming?
Your application may keep operating while it waits for lengthy processes to finish, such network operations, database queries, file IO, or API calls, thanks to asynchronous programming.

Example of Synchronous (Blocking)

var data = DownloadFile(); // Blocks the thread
Console.WriteLine("Done");

The thread waits (blocks) until DownloadFile completes.

Asynchronous (Non-blocking) Example
var data = await DownloadFileAsync();
Console.WriteLine("Done");

The thread does not block and can do other work while waiting.

Understanding async and await
1. async keyword

Used on methods.

Allows using the await keyword inside.

Converts the method into an asynchronous method.

2. await keyword

Pauses the method.

Frees the thread to do other work.

Resumes execution when the awaited task completes.

Example
public async Task<string> GetMessageAsync()
{
await Task.Delay(2000); // simulate time-consuming work
return "Hello from async!";
}

Why async and await Improve Performance?

• They do not create new threads.
• They free the current thread until work is done.
• They allow the server or UI to stay responsive.
• They help scale web APIs to handle more requests.
• How to Use async and await in Real .NET Applications

1. Asynchronous Methods Should Return Task or Task
Correct
public async Task SaveDataAsync() { }
public async Task<string> LoadDataAsync() { return "data"; }

Incorrect
public async void SaveData() { } // Avoid async void!

Why avoid async void?
Exceptions cannot be caught.

Difficult to test.

Only safe for event handlers:
private async void Button_Click(object sender, EventArgs e)
{
await LoadDataAsync();
}

2. Always await asynchronous calls
If you forget to use await, the method becomes fire-and-forget, leading to bugs.

Incorrect
SaveDataAsync(); // not awaited
Console.WriteLine("Done");

Correct
await SaveDataAsync();
Console.WriteLine("Done");

3. Use async all the way down
If your top-level method is async, everything it calls should also be async.

Anti-pattern
public void Process()
{
var result = GetDataAsync().Result; // Deadlock risk
}

Correct
public async Task ProcessAsync()
{
var result = await GetDataAsync();
}

4. Avoid .Result and .Wait()
These block the thread and can cause deadlocks, especially in ASP.NET and UI apps.

Example of problem
var data = GetDataAsync().Result; // blocks

Fix
var data = await GetDataAsync();

5. Use ConfigureAwait(false) in library code
This prevents capturing the original context unnecessarily.

Example
await Task.Delay(1000).ConfigureAwait(false);

Use this when writing:

• Class libraries
• SDKs

Background services
Do NOT use it in ASP.NET or UI where context matters.

6. Combine multiple async tasks with Task.WhenAll
When tasks can run in parallel, use Task.WhenAll.

Example
var t1 = GetUserAsync();
var t2 = GetOrdersAsync();
var t3 = GetPaymentsAsync();

await Task.WhenAll(t1, t2, t3);

Console.WriteLine(t1.Result);

This improves speed by running tasks simultaneously.

7. Do NOT wrap synchronous code in Task.Run unnecessarily
Bad example:
await Task.Run(() => File.ReadAllText("data.txt"));

Use actual async method:
await File.ReadAllTextAsync("data.txt");

Task.Run is only useful for CPU-bound tasks.

8. Async for CPU-bound vs I/O-bound tasks
I/O-bound example (network, file, DB)

Use async methods:
await httpClient.GetStringAsync(url);

CPU-bound example (calculation)

Use Task.Run:
await Task.Run(() => HeavyCalculation());

9. Handle exceptions in async methods
Use try/catch:
try
{
var data = await LoadDataAsync();
}
catch(Exception ex)
{
Console.WriteLine(ex.Message);
}

Exceptions flow automatically through async tasks when awaited.

10. Use CancellationToken for long-running async tasks
Example
public async Task DownloadAsync(CancellationToken token)
{
for (int i = 0; i < 10; i++)
{
    token.ThrowIfCancellationRequested();
    await Task.Delay(500);
}
}

This improves performance and user experience.

Full Example of Async Await in a .NET API
[HttpGet("/products")]
public async Task<IActionResult> GetProducts()
{
var list = await _service.GetProductsAsync();
return Ok(list);
}

Here:

• The request does not block
• Server can serve other users at the same time
• API becomes more scalable

Best Practices Summary

• Use async/await for I/O tasks
• Avoid async void except for events
• Avoid blocking calls: .Wait(), .Result
• Use Task.WhenAll for parallel asynchronous work
• Propagate async through method calls
• Handle cancellation properly

Conclusion
One of the most crucial abilities for.NET developers is the proper use of async and await. These keywords improve the speed, responsiveness, and scalability of your applications, particularly when handling database operations, file IO, and network calls. You may avoid common pitfalls and create dependable, high-performance.NET apps by adhering to the best practices in this tutorial, which include avoiding blocking calls, adopting Task-based patterns, and writing async all the way down.

One of the most crucial steps in creating web apps that are ready for production is validation. Inadequate validation could result in users submitting malicious, erroneous, or incomplete data, which could cause logic errors, inconsistent business processes, database corruption, and security flaws. A built-in model validation framework for Razor pages, controllers, and basic APIs is offered by ASP.NET Core. For complicated real-world scenarios, it is built on attributes, reusable rules, and optional custom logic. Validation ensures that the backend does not trust frontend data blindly, even if Angular, React, or Blazor already perform client-side checks.

This article examines how model validation works in real-life enterprise development with step-by-step implementation, examples, and best practices.

Problem Statement in the Real World
A freight booking web application was developed by a logistics company. Users could submit shipment weight, dimensions, pick-up date, and client information using their front-end user interface. At first, validation was limited to Angular, presuming that backend security was not required.

Within three months:

• Incorrect data formats reached the database.
• Some required fields were missing because users bypassed validation using developer tools.
• Negative weight values caused pricing miscalculations.
• Fake customer emails made automated notifications fail.

After an internal audit, the engineering team implemented server-side validation using ASP.NET Core Model Validation.

How Model Validation Works in ASP.NET Core

• When a request is received, ASP.NET Core automatically attempts to bind request data to the model.
• Validation attributes defined on properties are checked.
• If validation fails, the request is immediately blocked.
• An appropriate error response is returned (usually 400 Bad Request).
• The controller method does not execute until the data is valid.

This approach ensures backend consistency even if client-side validation is bypassed.

Basic Example Model with Required and Range Validation
public class BookingRequest
{
    [Required(ErrorMessage = "Customer Name is required.")]
    public string CustomerName { get; set; }

    [Required]
    [EmailAddress(ErrorMessage = "Invalid email format.")]
    public string Email { get; set; }

    [Range(1, 10000, ErrorMessage = "Weight must be between 1 and 10000 kg.")]
    public decimal Weight { get; set; }

    [Required]
    public DateTime PickupDate { get; set; }
}

Controller Example
[ApiController]
[Route("api/[controller]")]
public class BookingController : ControllerBase
{
    [HttpPost("create")]
    public IActionResult CreateBooking([FromBody] BookingRequest request)
    {
        if (!ModelState.IsValid)
        {
            return BadRequest(ModelState);
        }

        return Ok("Booking Created Successfully");
    }
}

Custom Validation Attribute Example
Real-world systems require rules beyond simple range or required fields. For example: block booking on weekends.
public class NoWeekendAttribute : ValidationAttribute
{
    public override bool IsValid(object value)
    {
        if (value is DateTime date)
        {
            return date.DayOfWeek != DayOfWeek.Saturday &&
                   date.DayOfWeek != DayOfWeek.Sunday;
        }

        return false;
    }
}

Apply it:
[NoWeekend(ErrorMessage = "Pickup date cannot be on weekends.")]
public DateTime PickupDate { get; set; }

Adding Cross-Field Validation Using IValidatableObject
Some business rules depend on multiple fields. Example: insured shipment requires a declared value.
public class Shipment : IValidatableObject
{
    public bool IsInsured { get; set; }
    public decimal? DeclaredValue { get; set; }

    public IEnumerable<ValidationResult> Validate(ValidationContext context)
    {
        if (IsInsured && DeclaredValue == null)
        {
            yield return new ValidationResult(
                "Declared value is required for insured shipments.",
                new[] { nameof(DeclaredValue) }
            );
        }
    }
}

Validation in Minimal APIs (ASP.NET Core 7+)
app.MapPost("/shipment", (Shipment shipment) =>
{
    if (!MiniValidator.TryValidate(shipment, out var errors))
        return Results.ValidationProblem(errors);

    return Results.Ok("Shipment processed");
});

Best Practices

• Never rely solely on client-side validation.
• Use meaningful validation messages.
• Encapsulate reusable logic in custom attributes.
• Use IValidatableObject only when cross-field logic is required.
• Version validation rules if business logic evolves.
• Log validation failures for auditing.

Common Mistakes to Avoid

Testing Validation

Use Postman or unit tests to verify behavior.

Example Unit Test
[Test]
public void Booking_ShouldFail_WhenWeightIsNegative()
{
    var model = new BookingRequest { Weight = -5 };

    var context = new ValidationContext(model);
    var results = new List<ValidationResult>();

    var isValid = Validator.TryValidateObject(model, context, results, true);

    Assert.IsFalse(isValid);
}

Final Recommendations

• Treat validation as part of the domain model, not just a UI feature.
• Keep validation rules consistent across systems.
• Validate early, validate everywhere, validate before storing data.

Conclusion
ASP.NET Core model validation is robust and adaptable. Your web application can handle data safely and consistently by using cross-property validation, custom rules, and built-in attributes. Validation lowers support requests, prevents damaged data, and increases program reliability in business settings. Validation of models is more than a feature. It is a precaution that keeps your system safe against deliberate abuse, automation mistakes, and human error.

Describe URL-Based Authentication.
Securing particular URLs, files, or route patterns so that only authorized users may access them is known as URL-based authentication.

Examples:
/admin only for Admins
/reports/daily only for Managers
/api/* only for logged-in users

1. URL-Based Authentication in ASP.NET Core
1.1 Protect a Folder or Route Pattern
Example: protect all URLs starting with /admin.
app.UseEndpoints(endpoints =>
{
    endpoints.MapControllerRoute(
        name: "admin",
        pattern: "admin/{controller=Dashboard}/{action=Index}/{id?}")
        .RequireAuthorization("AdminOnly");
});

Authorization policy:
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("AdminOnly",
        policy => policy.RequireRole("Admin"));
});

1.2 Protect a Specific URL
app.MapGet("/reports/daily", () => "Daily Report")
   .RequireAuthorization("ManagerOnly");
Policy:

options.AddPolicy("ManagerOnly",
    policy => policy.RequireRole("Manager"));
});
1.3 Protect Controller Actions
[Authorize(Roles = "Admin")]
public IActionResult Settings()
{
    return View();
}

This protects the URL /settings.

1.4 Custom Middleware to Block URLs
app.Use(async (context, next) =>
{
    var path = context.Request.Path.Value;

    if (path.StartsWith("/secret") && !context.User.Identity.IsAuthenticated)
    {
        context.Response.Redirect("/account/login");
        return;
    }

    await next();
});

2. URL-Based Authentication in Classic ASP.NET MVC (Non-Core)
2.1 Protect a Folder Using web.config
<location path="Admin">
  <system.web>
    <authorization>
      <deny users="?" />
      <allow roles="Admin" />
    </authorization>
  </system.web>
</location>

2.2 Protect a Single Page
<location path="Reports/Monthly.aspx">
  <system.web>
    <authorization>
      <deny users="?" />
      <allow roles="Manager" />
    </authorization>
  </system.web>
</location>

2.3 Protect Controller URL
[Authorize(Roles = "Admin")]
public ActionResult Dashboard()
{
    return View();
}

3. Role-Based URL Control Example
[Authorize(Roles = "Admin, Manager")]
public IActionResult Index()
{
    return View();
}
Route level:

endpoints.MapControllerRoute(
    name: "report",
    pattern: "reports/{*any}")
    .RequireAuthorization("ManagerOnly");

4. URL-Based Authentication for Web APIs
[Authorize]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    [HttpGet("{id}")]
    public IActionResult Get(int id)
    {
        return Ok();
    }
}

Protect all order-related API URLs:
app.MapControllerRoute("api-protected", "api/orders/{*path}")
   .RequireAuthorization();

Conclusion
ASP.NET Core provides middleware, routing, and policies for URL-based protection. Classic ASP.NET MVC uses web.config and Authorize attributes.

Key Functional Requirements
Users can type comments.
Auto-suggestions appear when typing @ for users.
Auto-suggestions appear when typing # for tags.
Comments should highlight mentions and hashtags.
Backend must store extracted mentions and tags.
Display comments with clickable mentions and hashtags.
Should support comment editing and deletion.

High-Level Workflow
User types comment →
Detect @mention or #tag →
Show suggestion list →
User selects item →
Submit comment →
Backend processes comment →
Save comment, mentions, tags →
Return formatted comment →
Display in UI

Sequence Diagram
User → Angular UI: Type comment
Angular UI → SuggestionService: Detect @ or #
SuggestionService → API: Fetch matching users or tags
API → Angular: Return suggestions
User → Angular: Select mention/tag
User → Angular: Submit final comment
Angular → API: Send comment text
API → Parser: Extract @mentions and #tags
Parser → DB: Save comment, mentions, tags
DB → API: Confirm save
API → Angular: Return formatted comment
Angular → User: Show updated comment list

Frontend Implementation (Angular)
Detecting Mentions and Hashtags in Textbox
<textarea
[(ngModel)]="commentText"
(keyup)="onKeyUp($event)"
placeholder="Write a comment...">
</textarea>

<div *ngIf="showSuggestions">
<ul class="suggestions">
<li *ngFor="let item of suggestions"
    (click)="selectSuggestion(item)">
  {{ item.display }}
</li>
</ul>
</div>

TypeScript Logic
onKeyUp(event: KeyboardEvent) {
  const text = this.commentText;
  const cursorPos = (event.target as HTMLTextAreaElement).selectionStart;

  const charBeforeCursor = text[cursorPos - 1];

  if (charBeforeCursor === '@') {
    this.loadUserSuggestions();
  }

  if (charBeforeCursor === '#') {
    this.loadTagSuggestions();
  }
}

loadUserSuggestions() {
  this.api.getUsers().subscribe(res => {
    this.showSuggestions = true;
    this.suggestions = res.map(u => ({ display: u.displayName, type: 'user', id: u.userId }));
  });
}

loadTagSuggestions() {
  this.api.getTags().subscribe(res => {
    this.showSuggestions = true;
    this.suggestions = res.map(t => ({ display: t.tagName, type: 'tag', id: t.tagId }));
  });
}

selectSuggestion(item: any) {
  const prefix = item.type === 'user' ? '@' : '#';
  this.commentText += prefix + item.display + ' ';
  this.showSuggestions = false;
}

Submitting the Comment
submitComment() {
  this.api.postComment({ content: this.commentText }).subscribe(() => {
    this.commentText = '';
    this.loadComments();
  });
}

Backend Implementation (ASP.NET Core)
Extracting Mentions and Tags
var mentions = Regex.Matches(model.Content, @"@(\w+)");
var tags = Regex.Matches(model.Content, @"#(\w+)");

API Controller

[HttpPost("comments")]
public async Task<IActionResult> PostComment(CommentDto model)
{
var comment = new Comment
{
    UserId = model.UserId,
    Content = model.Content,
    CreatedOn = DateTime.UtcNow
};

_db.Comments.Add(comment);
await _db.SaveChangesAsync();

// Extract mentions
var mentions = Regex.Matches(model.Content, @"@(\w+)")
                     .Select(m => m.Groups[1].Value)
                     .ToList();

foreach (var m in mentions)
{
    var user = _db.Users.FirstOrDefault(u => u.DisplayName == m);
    if (user != null)
    {
        _db.CommentMentions.Add(new CommentMention
        {
            CommentId = comment.CommentId,
            MentionedUserId = user.UserId
        });
    }
}

// Extract hashtags
var tags = Regex.Matches(model.Content, @"#(\w+)")
                .Select(m => m.Groups[1].Value)
                .ToList();

foreach (var t in tags)
{
    var tag = _db.Tags.FirstOrDefault(x => x.TagName == t)
              ?? new Tag { TagName = t };

    _db.CommentTags.Add(new CommentTag
    {
        CommentId = comment.CommentId,
        TagId = tag.TagId
    });
}

await _db.SaveChangesAsync();

return Ok();
}

Displaying Mentions and Hashtags with Highlighting
Angular Pipe
transform(value: string): string {
  value = value.replace(/@(\w+)/g, `<span class="mention">@$1</span>`);
  value = value.replace(/#(\w+)/g, `<span class="hashtag">#$1</span>`);
  return value;
}

UI Styling
.mention { color: #0275d8; font-weight: bold; }
.hashtag { color: #5cb85c; font-weight: bold; }
.suggestions { list-style: none; margin: 0; padding: 0; background: #f5f5f5; }
.suggestions li { padding: 6px; cursor: pointer; }

Best Practices

• Use caching for user and tag suggestions to improve performance
• Avoid over-querying the database
• Rate-limit comment submission
• Support soft delete for comments
• Implement pagination for comment lists
• Add real-time support using SignalR if needed

Conclusion
A comment system with mentions and hashtags adds professional collaboration capabilities to any web application. By using Angular for real-time processing and ASP.NET Core for strong backend parsing, you can build a scalable and reusable module. The design shown here works for enterprise portals, task management systems, social feeds, project tracking tools, LMS platforms, and more.