Using Custom Middleware to Implement Enterprise-Grade Global Exception Handling

For reliable production applications, error handling must be done correctly. Using custom middleware or centralized exception handlers,.NET Core enables you to record unhandled exceptions globally rather than encasing each controller action or minimum endpoint handler in repeating try-catch blocks.

This method guarantees that your whole API ecosystem uses the same JSON error response structure.
First, develop a standardized error response model.

To enable frontend clients to parse errors consistently, establish a predictable format for your error payload.

public class ErrorDetails
{
    public int StatusCode { get; set; }
    public string Message { get; set; } = string.Empty;
    public string? Details { get; set; }
    public DateTime Timestamp { get; set; } = DateTime.UtcNow;

    public override string ToString() => System.Text.Json.JsonSerializer.Serialize(this);
}

Step 2: Build the Custom Exception Handling Middleware

Create a middleware component that intercepts exceptions flowing down the HTTP pipeline, logs them securely, and writes a uniform JSON payload back to the client.

using System.Net;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;

public class GlobalExceptionHandlingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<GlobalExceptionHandlingMiddleware> _logger;
    private readonly IWebHostEnvironment _env;

    public GlobalExceptionHandlingMiddleware(
        RequestDelegate next,
        ILogger<GlobalExceptionHandlingMiddleware> logger,
        IWebHostEnvironment env)
    {
        _next = next;
        _logger = logger;
        _env = env;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            // Move to the next middleware in the pipeline
            await _next(context);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "An unhandled exception occurred during execution: {Message}", ex.Message);
            await HandleExceptionAsync(context, ex);
        }
    }

    private async Task HandleExceptionAsync(HttpContext context, Exception exception)
    {
        context.Response.ContentType = "application/json";

        // Default to Internal Server Error
        var statusCode = (int)HttpStatusCode.InternalServerError;
        var message = "An internal server error has occurred.";

        // Custom domain or validation exceptions can be handled explicitly here
        if (exception is KeyNotFoundException)
        {
            statusCode = (int)HttpStatusCode.NotFound;
            message = "The requested resource was not found.";
        }
        else if (exception is UnauthorizedAccessException)
        {
            statusCode = (int)HttpStatusCode.Unauthorized;
            message = "Authentication is required to access this resource.";
        }

        context.Response.StatusCode = statusCode;

        var errorDetails = new ErrorDetails
        {
            StatusCode = statusCode,
            Message = message,
            // Expose stack trace details only if running in Development environment
            Details = _env.IsDevelopment() ? exception.StackTrace : null
        };

        await context.Response.WriteAsync(errorDetails.ToString());
    }
}

Step 3: Register an Extension Method for Clean Setup

To keep Program.cs clean and modular, wrap the middleware registration in an extension class.

public static class MiddlewareExtensions
{
    public static IApplicationBuilder UseGlobalExceptionHandling(this IApplicationBuilder app)
    {
        return app.UseMiddleware<GlobalExceptionHandlingMiddleware>();
    }
}

Step 4: Wire Up the Middleware in Program.cs

Register your custom middleware at the very beginning of the HTTP request pipeline so it wraps all subsequent operations (such as routing, endpoint execution, and authentication).

var builder = WebApplication.CreateBuilder(args);

// Add services...
builder.Services.AddControllers();

var app = builder.Build();

// 1. Place the exception handling middleware first in the pipeline execution tree
app.UseGlobalExceptionHandling();

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

// Test endpoint designed to throw an exception on purpose
app.MapGet("/error-test", () =>
{
    throw new InvalidOperationException("Simulated catastrophic failure for middleware testing.");
});

app.Run();

Step 5: Test the Global Handler

Run your application (dotnet run) and navigate to https://localhost:{port}/error-test.

Instead of an unhandled server crash, raw HTML error dump, or dropped connection, the pipeline intercepts the InvalidOperationException and safely responds with a structured, production-ready JSON error object:

{
  "statusCode": 500,
  "message": "An internal server error has occurred.",
  "details": "   at Program.<>c.<__ hfl line>...",
  "timestamp": "2026-08-03T09:00:00Z"
}

Best ASP.NET Core 10.0 Hosting Recommendation

One of the most important things when choosing a good ASP.NET Core 8.0 hosting is the feature and reliability. HostForLIFE is the leading provider of Windows hosting and affordable ASP.NET Core, their servers are optimized for PHP web applications. The performance and the uptime of the hosting service are excellent and the features of the web hosting plan are even greater than what many hosting providers ask you to pay for. 

At HostForLIFEASP.NET, customers can also experience fast ASP.NET Core hosting. The company invested a lot of money to ensure the best and fastest performance of the datacenters, servers, network and other facilities. Its datacenters are equipped with the top equipments like cooling system, fire detection, high speed Internet connection, and so on. That is why HostForLIFEASP.NET guarantees 99.9% uptime for ASP.NET Core. And the engineers do regular maintenance and monitoring works to assure its Orchard hosting are security and always up.

Read More...

Dual-Layer Rate Limiting Middleware for Enterprise LangGraph RAG

Large Language Models (LLMs) are already essential infrastructure in the corporate AI world of 2026, not only a curiosity. Nevertheless, LLM inference is computationally demanding and costly by nature. The "noisy neighbor" issue, budget-draining prompt injection loops, and misuse are all possible when a multi-agent Retrieval-Augmented Generation (RAG) system is exposed through an API.

 

A single client spamming your RAG endpoint has the potential to deplete your LLM token quotas, increase your cloud compute expenses, and worsen latency for all other users. An end-to-end tutorial for setting up a Dual-Layer Rate Limiting Middleware in FastAPI is given in this article. In order to enforce restrictions, we will return standard 429 Too Many Requests replies based on both Client IP (for anonymous/internal traffic) and API Key (for authorized partners). Lastly, a production-grade Multi-Agent LangGraph RAG system with permanent memory and state will be integrated with this middleware. 

Part 1: The Enterprise Use Case

Scenario: "Acme Corp" has deployed an internal/external AI Knowledge Assistant. The system uses a multi-agent LangGraph architecture to retrieve data from Confluence, Jira, and internal wikis, and synthesize answers.

The Access Tiers:

1. Authenticated Partners (API Key): Have a strict limit (e.g., 60 requests per minute) to prevent automated script abuse.

2. Internal Employees (Corporate IP): Have a higher limit (e.g., 120 requests per minute) as they are trusted internal users.

3. Anonymous Web Chat (Public IP): Have the lowest limit (e.g., 20 requests per minute) to prevent bot attacks.

The Architecture:

• FastAPI Gateway: Handles HTTP routing, authentication extraction, and rate limiting.

• Redis: Acts as the distributed, high-performance counter for rate limits.

• LangGraph Backend: Executes the multi-agent RAG workflow, maintaining conversation state via a Checkpointer.

Part 2: Designing the Dual-Layer Rate Limiter

To build an enterprise-grade rate limiter, we must address three challenges:

1. Distributed State: If your FastAPI app runs on multiple replicas (Kubernetes pods), in-memory counters will fail. We must use Redis.

2. Race Conditions: A simple GET then SET in Redis is not atomic. We will use Redis INCR with an expiration to ensure thread safety.

3. Header Standards: When rejecting a request with a 429, we must return standard headers (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After) so client applications can handle the backoff gracefully.

Part 3: The Code Implementation

Below is the complete, end-to-end implementation.

1. Dependencies

pip install fastapi uvicorn redis langchain-openai langgraph langchain-core pydantic

2. The Redis Rate Limiter & FastAPI Middleware

import time
import logging
from typing import Optional, Tuple
from fastapi import FastAPI, Request, HTTPException
from fastapi.responses import JSONResponse
from starlette.middleware.base import BaseHTTPMiddleware
import redis.asyncio as redis

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Initialize Redis connection (Enterprise: Use a connection pool)
redis_client = redis.from_url("redis://localhost:6379", decode_responses=True)

class DualLayerRateLimiter:
    """Handles the logic for checking and incrementing rate limits in Redis."""

    def __init__(self, redis_conn: redis.Redis):
        self.redis = redis_conn

    async def check_limit(self, identifier: str, limit: int, window_seconds: int) -> Tuple[bool, int, int]:
        """
        Checks the rate limit. Uses a sliding/fixed window approach.
        Returns: (is_allowed, remaining_requests, limit)
        """
        # Create a time-bounded key (Fixed window per minute)
        current_window = int(time.time() // window_seconds)
        redis_key = f"ratelimit:{identifier}:{current_window}"

        # Atomic increment. If key doesn't exist, it's created with value 1.
        current_count = await self.redis.incr(redis_key)

        # Set expiration only on the first request of the window to prevent race conditions
        if current_count == 1:
            await self.redis.expire(redis_key, window_seconds + 1) # +1s buffer

        is_allowed = current_count <= limit
        remaining = max(0, limit - current_count)

        return is_allowed, remaining, limit

class RateLimitMiddleware(BaseHTTPMiddleware):
    """
    FastAPI Middleware that intercepts requests, extracts IP/API Key,
    and enforces dual-layer rate limiting.
    """
    def __init__(self, app, limiter: DualLayerRateLimiter):
        super().__init__(app)
        self.limiter = limiter
        # Define tiers: (limit per minute)
        self.api_key_limit = 60
        self.internal_ip_limit = 120
        self.public_ip_limit = 20
        self.window = 60 # 60 seconds

    async def dispatch(self, request: Request, call_next):
        # Skip rate limiting for health checks and docs
        if request.url.path in ["/health", "/docs", "/openapi.json"]:
            return await call_next(request)

        # 1. Extract Client IP (Handling reverse proxies like AWS ALB / Nginx)
        forwarded_for = request.headers.get("X-Forwarded-For")
        if forwarded_for:
            client_ip = forwarded_for.split(",")[0].strip()
        else:
            client_ip = request.client.host if request.client else "unknown"

        # 2. Extract API Key
        api_key = request.headers.get("X-API-Key") or request.headers.get("Authorization", "").replace("Bearer ", "")

        # 3. Determine Identifier and Limit Tier
        if api_key and api_key != "":
            identifier = f"key:{api_key}"
            limit = self.api_key_limit
            tier = "API_KEY"
        elif client_ip.startswith("10.") or client_ip.startswith("192.168."): # Mock internal IP check
            identifier = f"ip:{client_ip}"
            limit = self.internal_ip_limit
            tier = "INTERNAL_IP"
        else:
            identifier = f"ip:{client_ip}"
            limit = self.public_ip_limit
            tier = "PUBLIC_IP"

        # 4. Check Limit
        is_allowed, remaining, max_limit = await self.limiter.check_limit(identifier, limit, self.window)

        if not is_allowed:
            logger.warning(f"Rate limit exceeded for {tier} {identifier}. Limit: {max_limit}")
            return JSONResponse(
                status_code=429,
                content={"error": "Too Many Requests", "message": "Rate limit exceeded. Please slow down."},
                headers={
                    "X-RateLimit-Limit": str(max_limit),
                    "X-RateLimit-Remaining": "0",
                    "Retry-After": str(self.window),
                    "X-RateLimit-Tier": tier
                }
            )

        # 5. Proceed and inject rate limit headers into the successful response
        response = await call_next(request)
        response.headers["X-RateLimit-Limit"] = str(max_limit)
        response.headers["X-RateLimit-Remaining"] = str(remaining)
        response.headers["X-RateLimit-Tier"] = tier
        return response

3. The Multi-Agent LangGraph RAG Backend

Now, we build the AI backend. We will use a multi-agent approach: a Router Agent directs the query to a RAG Retriever Agent, which passes context to a Synthesizer Agent. We use LangGraph's Checkpointer for memory.

from typing import TypedDict, Annotated, Sequence, Literal
from langchain_core.messages import BaseMessage, HumanMessage, AIMessage, SystemMessage
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, END
from langgraph.checkpoint.memory import MemorySaver
from langchain_core.tools import tool

# --- 1. Define the State ---
class GraphState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], "The conversation history"]
    user_id: str
    retrieved_context: str
    next_agent: str

# --- 2. Define the Tools (RAG) ---
@tool
def search_internal_knowledge_base(query: str) -> str:
    """Searches the enterprise vector database for internal policies and documentation."""
    # In production, this queries Pinecone/Milvus/Weaviate
    return "Acme Corp Policy: Employees are entitled to 25 days of PTO. Rollover is permitted up to 5 days."

# --- 3. Define the Agent Nodes ---
llm = ChatOpenAI(model="gpt-4o", temperature=0)

async def router_node(state: GraphState):
    """Determines if the query requires RAG or can be answered directly."""
    # Simplified routing logic for demonstration
    messages = state["messages"]
    last_msg = messages[-1].content.lower()

    if "policy" in last_msg or "pto" in last_msg or "hr" in last_msg:
        return {"next_agent": "rag_retriever"}
    return {"next_agent": "synthesizer"}

async def rag_retriever_node(state: GraphState):
    """Executes the RAG tool and stores context in state."""
    last_msg = state["messages"][-1].content
    # In a real agent, the LLM would decide the tool arguments
    context = search_internal_knowledge_base.invoke({"query": last_msg})
    return {"retrieved_context": context, "next_agent": "synthesizer"}

async def synthesizer_node(state: GraphState):
    """Synthesizes the final answer using the LLM and retrieved context."""
    context = state.get("retrieved_context", "No specific context retrieved.")
    messages = state["messages"]

    prompt = [
        SystemMessage(content=f"You are an enterprise AI assistant. Use the following context to answer the user:\n\nContext: {context}\n\nIf the context doesn't contain the answer, state that you don't know."),
        *messages
    ]

    response = await llm.ainvoke(prompt)
    return {"messages": [response], "next_agent": "end"}

# --- 4. Build and Compile the Graph ---
def route_next(state: GraphState) -> Literal["rag_retriever", "synthesizer", "end"]:
    return state["next_agent"]

workflow = StateGraph(GraphState)
workflow.add_node("router", router_node)
workflow.add_node("rag_retriever", rag_retriever_node)
workflow.add_node("synthesizer", synthesizer_node)

workflow.set_entry_point("router")
workflow.add_conditional_edges("router", route_next)
workflow.add_edge("rag_retriever", "synthesizer")
workflow.add_edge("synthesizer", END)

# Initialize Memory (Enterprise: Use AsyncPostgresSaver)
memory = MemorySaver()
rag_graph = workflow.compile(checkpointer=memory)

4. Tying it Together: The FastAPI App

from pydantic import BaseModel

app = FastAPI(title="Enterprise RAG Gateway")

# Initialize Limiter and Middleware
limiter = DualLayerRateLimiter(redis_client)
app.add_middleware(RateLimitMiddleware, limiter=limiter)

class ChatRequest(BaseModel):
    message: str
    user_id: str
    thread_id: str # Used for LangGraph memory checkpointing

@app.post("/v1/chat")
async def chat_endpoint(payload: ChatRequest, request: Request):
    """
    The main endpoint. Protected by the RateLimitMiddleware.
    Invokes the LangGraph asynchronously.
    """
    # Extract user identity for LangGraph state
    user_id = payload.user_id
    thread_id = payload.thread_id

    # Prepare LangGraph config for memory persistence
    config = {"configurable": {"thread_id": thread_id}}

    # Initial state input
    inputs = {
        "messages": [HumanMessage(content=payload.message)],
        "user_id": user_id,
        "retrieved_context": "",
        "next_agent": ""
    }

    try:
        # Invoke the multi-agent graph asynchronously
        final_state = await rag_graph.ainvoke(inputs, config)

        # Extract the final AI response
        ai_message = final_state["messages"][-1].content

        return {
            "response": ai_message,
            "thread_id": thread_id,
            "metadata": {
                "agents_used": ["router", "rag_retriever", "synthesizer"],
                "user_id": user_id
            }
        }
    except Exception as e:
        logger.error(f"LangGraph execution failed: {str(e)}")
        raise HTTPException(status_code=500, detail="Internal AI processing error")

@app.get("/health")
async def health_check():
    return {"status": "healthy", "timestamp": time.time()}

Part 4: Testing the Implementation

To test this, run the FastAPI app (uvicorn main:app --reload) and use curl to simulate traffic.

Test 1: Normal Request (API Key)

curl -X POST "http://localhost:8000/v1/chat" \
-H "X-API-Key: partner_key_123" \
-H "Content-Type: application/json" \
-d '{"message": "What is the PTO policy?", "user_id": "user_1", "thread_id": "thread_99"}' \
-i

Expected Response: 200 OK with headers X-RateLimit-Limit: 60 and X-RateLimit-Remaining: 59. The AI will correctly retrieve and synthesize the PTO policy using the RAG agent.

Test 2: Triggering the 429 Rate Limit

Run a quick loop to exhaust the public IP limit (20 requests/minute).

for i in {1..25}; do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST "http://localhost:8000/v1/chat" \
  -H "Content-Type: application/json" \
  -d '{"message": "Hello", "user_id": "user_2", "thread_id": "thread_100"}'
done

Expected Output: The first 20 requests will return 200. The remaining 5 will return 429.

If you inspect the headers of the 429 response:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 20
X-RateLimit-Remaining: 0
Retry-After: 60
X-RateLimit-Tier: PUBLIC_IP
Content-Type: application/json

{"error": "Too Many Requests", "message": "Rate limit exceeded. Please slow down."}

Test 3: Verifying Memory and State

Send a follow-up message using the same thread_id to prove the LangGraph Checkpointer is maintaining state across requests.

curl -X POST "http://localhost:8000/v1/chat" \
-H "X-API-Key: partner_key_123" \
-H "Content-Type: application/json" \
-d '{"message": "Can I rollover more than 5 days?", "user_id": "user_1", "thread_id": "thread_99"}'

Expected Response: The AI will remember the previous context about the 5-day rollover limit without needing the RAG tool to fetch it again, demonstrating successful state persistence.

Part 5: Enterprise Best Practices & Next Steps

Implementing this architecture gives you a robust, production-ready AI gateway. However, to fully harden this for a Fortune 500 deployment, consider the following enhancements:

1. Atomic Lua Scripts in Redis: While INCR and EXPIRE work well, a strict enterprise environment should use a Redis Lua script to perform the check-and-set atomically, preventing edge-case race conditions during high-concurrency spikes.

2. Token-Based Rate Limiting: Instead of limiting by requests, limit by LLM tokens. A request that generates 10,000 tokens should cost more against the rate limit than a request generating 100 tokens. You can intercept the LangGraph output, calculate token usage, and decrement a Redis token bucket.

3. Distributed Checkpointing: In the code above, we used MemorySaver for brevity. In production, you must swap this for AsyncPostgresSaver or AsyncRedisSaver so that conversation memory survives FastAPI pod restarts and scales horizontally.

4. Circuit Breakers: Combine this rate limiter with a circuit breaker (like pybreaker). If the underlying vector database or LLM provider goes down, the circuit breaker should immediately return a 503 without wasting time executing the LangGraph nodes.

By combining FastAPI's dual-layer rate limiting with LangGraph's stateful multi-agent execution, you ensure that your enterprise AI is not only intelligent and context-aware but also financially predictable and highly resilient to abuse.

ASP.NET Core 10.0 Hosting Recommendation

One of the most important things when choosing a good ASP.NET Core 9.0 hosting is the feature and reliability. HostForLIFE is the leading provider of Windows hosting and affordable ASP.NET Core, their servers are optimized for PHP web applications. The performance and the uptime of the hosting service are excellent and the features of the web hosting plan are even greater than what many hosting providers ask you to pay for. 

At HostForLIFE.eu, customers can also experience fast ASP.NET Core hosting. The company invested a lot of money to ensure the best and fastest performance of the datacenters, servers, network and other facilities. Its datacenters are equipped with the top equipments like cooling system, fire detection, high speed Internet connection, and so on. That is why HostForLIFEASP.NET guarantees 99.9% uptime for ASP.NET Core. And the engineers do regular maintenance and monitoring works to assure its Orchard hosting are security and always up.

 

 

Read More...

Using ASP.NET Core's BackgroundService for Prolonged Tasks

An application shouldn't execute all of its tasks as part of an HTTP request. While certain processes must run continually in the background, others take a long time to finish. Email processing, report generation, data synchronization, temporary file cleanup, and message consumption from a queue are a few examples.

Your application may become slower and provide a worse user experience if these actions are executed directly within a controller or API endpoint. To address this issue, ASP.NET Core offers the BackgroundService class.

With BackgroundService, you can maintain the responsiveness and scalability of your application while doing lengthy activities independently of incoming HTTP requests.

This post will teach you how to utilize BackgroundService, when to use it, and how to create dependable background processes in ASP.NET Core.

What Is BackgroundService?

BackgroundService is an abstract class provided by ASP.NET Core for implementing hosted services that run in the background.

Unlike a controller, a background service starts when the application starts and continues running until the application stops.

Some common use cases include:

• Sending emails

• Processing message queues

• Importing data from external systems

• Scheduled cleanup tasks

• Generating reports

• Monitoring application health

• Processing uploaded files

Since these operations run independently, they don't block incoming user requests.

Creating a Background Service

Creating a background service is simple. Create a class that inherits from BackgroundService.

using Microsoft.Extensions.Hosting;

public class WorkerService : BackgroundService
{
    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            Console.WriteLine("Background task is running...");

            await Task.Delay(5000, stoppingToken);
        }
    }
}

The ExecuteAsync method contains the logic that runs continuously until the application shuts down.

Registering the Background Service

After creating the service, register it with the dependency injection container.

builder.Services.AddHostedService<WorkerService>();

When the application starts, ASP.NET Core automatically starts the background service.

No additional configuration is required.

Understanding the Cancellation Token

A background service should always respond gracefully when the application is shutting down.

ASP.NET Core provides a CancellationToken that signals when the service should stop.

Example:

while (!stoppingToken.IsCancellationRequested)
{
    await ProcessDataAsync();

    await Task.Delay(10000, stoppingToken);
}

Checking the cancellation token ensures that the application can shut down cleanly without leaving unfinished operations.

Processing Queue Messages

One of the most common uses of BackgroundService is processing messages from a queue.

A typical workflow looks like this:

1. A user submits a request.

2. The application places a message in a queue.

3. The API immediately returns a response.

4. The background service reads the message.

5. The task is processed asynchronously.

This approach improves responsiveness because users don't have to wait for lengthy operations to complete.

Using Dependency Injection

Background services can use other application services through dependency injection.

For example:

public class WorkerService : BackgroundService
{
    private readonly ILogger<WorkerService> _logger;

    public WorkerService(ILogger<WorkerService> logger)
    {
        _logger = logger;
    }

    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _logger.LogInformation("Worker is running.");

            await Task.Delay(5000, stoppingToken);
        }
    }
}

This makes it easy to use logging, database services, or other application components inside the background service.

Handle Exceptions Properly

A background service should never stop unexpectedly because of an unhandled exception.

Instead, catch exceptions, log them, and continue processing when appropriate.

try
{
    await ProcessOrdersAsync();
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

Proper exception handling improves application reliability and simplifies troubleshooting.

Avoid Blocking Operations

Background services should use asynchronous methods whenever possible.

Instead of:

Thread.Sleep(5000);

Use:

await Task.Delay(5000, stoppingToken);

Asynchronous operations free application threads to handle other work, improving scalability.

Real-World Example

Imagine an online shopping application.

When a customer places an order:

1. The API saves the order.

2. A message is added to a queue.

3. The API immediately returns a success response.

4. A background service processes the order.

5. The service sends a confirmation email.

6. Inventory is updated.

7. A shipping request is created.

The customer receives an immediate response while the remaining tasks continue in the background.

Best Practices

When using BackgroundService in ASP.NET Core, follow these recommendations:

• Keep background tasks independent of HTTP requests.

• Always use the provided CancellationToken.

• Prefer asynchronous operations over blocking calls.

• Handle exceptions to prevent unexpected service termination.

• Use dependency injection instead of creating services manually.

• Log important events and errors for easier monitoring.

• Avoid performing CPU-intensive work on the main application thread.

• Monitor background service performance and resource usage in production.

Conclusion

BackgroundService provides a clean and reliable way to run long-running tasks in ASP.NET Core applications. By moving work such as email processing, queue consumption, report generation, and scheduled maintenance outside the request pipeline, you can improve application responsiveness and deliver a better user experience.

When combined with dependency injection, asynchronous programming, and proper error handling, BackgroundService becomes a powerful tool for building scalable and maintainable applications. By following the best practices outlined in this article, you can create background processes that run efficiently and reliably in production environments.

ASP.NET Core 10.0 Hosting Recommendation

One of the most important things when choosing a good ASP.NET Core 10.0 hosting is the feature and reliability. HostForLIFE is the leading provider of Windows hosting and affordable ASP.NET Core 10.0, their servers are optimized for PHP web applications. The performance and the uptime of the hosting service are excellent and the features of the web hosting plan are even greater than what many hosting providers ask you to pay for. 

At HostForLIFE.eu, customers can also experience fast ASP.NET Core hosting. The company invested a lot of money to ensure the best and fastest performance of the datacenters, servers, network and other facilities. Its datacenters are equipped with the top equipments like cooling system, fire detection, high speed Internet connection, and so on. That is why HostForLIFE guarantees 99.9% uptime for ASP.NET Core. And the engineers do regular maintenance and monitoring works to assure its Orchard hosting are security and always up.

Read More...

Creating a Low-Allocation, Streaming Excel Writer in .NET

You've undoubtedly faced the same issue if you've ever dealt with Excel creation in.NET: creating a basic.xlsx file requires allocating tens or even hundreds of gigabytes of RAM. Well-known libraries like EPPlus or ClosedXML typically allot 30–100 MB for a 10,000-row dataset with four string columns. Only when a web API is offering file downloads under concurrent load does this issue get worse.

The main methods I employed to create a zero-dependency Excel writer that uses less than 1 MB for the same 10,000-row workload and finishes 8–10× quicker are described in this post. IBufferWriter integration, streaming techniques, OOXML internals, and real-world benchmark comparisons will all be covered.

Why OOXML?

An .xlsx file is just a ZIP archive containing XML files. The structure is well-defined:

• [Content_Types].xml – Content type declarations

• _rels/.rels – Package-level relationships

• xl/workbook.xml – Workbook definition (sheet names)

• xl/_rels/workbook.xml.rels – Workbook relationships

• xl/styles.xml – Cell styles

• xl/sharedStrings.xml – Shared string table (optional)

• xl/worksheets/sheet1.xml – Sheet data

• xl/theme/theme1.xml – Theme definition (optional)

This means we don't need any third-party library to generate a valid .xlsx file. We just need to:

1. Write XML parts to a ZIP stream

2. Handle the OPC (Open Packaging Convention) relationship structure

3. Manage cell data, styles, and shared strings efficiently

Technique 1: Direct-to-Stream Writing

Most Excel libraries build an in-memory DOM first, then serialize it. ClosedXML, for example, builds an entire XLWorkbook object graph with IXLRow, IXLCell, styles, formulas, etc. — all in memory — before writing.

A streaming approach flips this: write XML directly to the output stream as data arrives. No intermediate object model.

Here's the core idea in simplified form:

// Traditional DOM approach: everything lives in memory
var workbook = new XLWorkbook();
var sheet = workbook.Worksheets.Add("Sheet1");
sheet.Cell(1, 1).Value = "Header";
// ... add 10,000 rows
workbook.SaveAs("output.xlsx");  // only now does serialization happen

// Streaming approach: write as we go
using var zip = new ZipArchive(stream, mode);
var sheetEntry = zip.CreateEntry("xl/worksheets/sheet1.xml");
using var sw = new StreamWriter(sheetEntry.Open());
sw.Write("<?xml version=\"1.0\"?>");
sw.Write("<worksheet xmlns=\"...\"><sheetData>");
foreach (var row in data)
{
    // Write row XML directly — no intermediate objects
    sw.Write($"<row><c t=\"inlineStr\"><is><t>{Escape(row.Name)}</t></is></c></row>");
}
sw.Write("</sheetData></worksheet>");

This pattern eliminates the entire in-memory object graph. The tradeoff is that you lose random access (no modifying cell B4 after writing row 100), but for export scenarios, you never need it anyway.

Technique 2: IBufferWriter<byte> for Low-Allocation Paths

.NET has a lesser-known gem: System.Buffers.IBufferWriter<byte>. It lets you write bytes directly into rented pooled buffers, avoiding intermediate byte[] allocations and copies.

Here's how it works in practice:

// Traditional: allocates a byte[]
var ms = new MemoryStream();
Xlsx.Write(ms, data);
byte[] result = ms.ToArray();  // another allocation + copy

// IBufferWriter: writes to pooled buffers
var writer = new ArrayBufferWriter<byte>();
Xlsx.Write(writer, data);
// writer.WrittenSpan is a ReadOnlySpan<byte> over rented memory
// No intermediate allocations

The IBufferWriter<byte> path is the primary low-allocation hot path. It chains through ZipArchive → DeflateStream → XML writer, all using IBufferWriter<byte> under the hood, eliminating allocations at every layer.

This is also the technique that System.Text.Json uses under the hood for its high-performance serialization — the same pattern applies to XML generation.

Technique 3: Inline Strings vs. Shared Strings Table (SST)

OOXML supports two ways to store string values:

Inline strings (t="inlineStr"): The string value lives directly inside the cell element. No shared strings file needed. This is optimal when strings are mostly unique.

Shared Strings Table (t="s" with index): Strings are stored once in xl/sharedStrings.xml, and cells reference them by index. This is optimal when strings are highly repeated (e.g., status values, categories).

Most libraries default to SST (or build it unconditionally), but SST is wasteful when strings are unique — you double the memory: once for the SST, once for the cell references.

My approach uses a heuristic: pre-scan the first 64 rows. If string deduplication ratio is below 70%, stay with inline strings. Only switch to SST when it actually saves space. This is similar to what Excel itself does when saving files.

// Auto-detect based on data characteristics
Xlsx.ToBytes(data, p => p.WithAutoSst(true));

// Benchmarks on 10k rows with 16 unique strings (96% dedup):
// SST path:  2,804 μs, 955 KB  — dedup saves XML space
// Inline:    2,933 μs, 979 KB  — inline avoids SST bookkeeping
// For unique strings, inline is both faster and smaller

Technique 4: Fluent Export Profiles

Rather than a verbose configuration object, a fluent API keeps the code readable and the allocation minimal:

// Fluent profile — no intermediate configuration objects allocated
var bytes = Xlsx.ToBytes(orders, p => p
    .Sheet("Orders")
    .Column(x => x.OrderNo, c => c.WithName("Order #").WithWidth(30))
    .Column(x => x.Amount,  c => c.WithFormat("0.00").WithFontColor("#0000FF"))
    .Ignore(x => x.InternalId)
    .WithFreezeHeader());

// Traditional (ClosedXML) — configuration mixed with data manipulation
using var wb = new XLWorkbook();
var ws = wb.Worksheets.Add("Orders");
ws.Cell(1, 1).Value = "Order #";  // mutating a DOM object
ws.Cell(1, 1).Style.Font.Bold = true;
// ...

The Action<ExportProfile<T>> callback is compiled into a delegate once (via Expression.Compile or source-gen fast paths with [XlsxExportable]), and the configuration is applied during streaming without allocating intermediate objects.

Technique 5: IAsyncEnumerable<T> for True Streaming

For web API scenarios where data comes from an async source (database, gRPC, event stream), IAsyncEnumerable<T> enables true end-to-end streaming:

// Database → stream → HTTP response — no materialized list
app.MapGet("/export/orders", async (HttpContext ctx, AppDbContext db) =>
{
    ctx.Response.ContentType = "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet";
    await Xlsx.WriteAsync(
        ctx.Response.Body,
        ReadOrdersAsync(db),  // IAsyncEnumerable<Order>
        p => p.Sheet("Orders"));
});

async IAsyncEnumerable<Order> ReadOrdersAsync(AppDbContext db)
{
    await foreach (var order in db.Orders.AsAsyncEnumerable()
        .Where(o => o.Status == OrderStatus.Active))
        yield return order;
}

This means the HTTP response body stream is written concurrently with the database query. At no point is the full dataset materialized in memory. Contrast this with:

// Traditional: load all data, then write
var orders = await db.Orders.Where(...).ToListAsync();  // materialized in memory
ClosedXML...SaveAs(stream);                              // writes from memory

The API is symmetric — reading also uses IAsyncEnumerable:

await foreach (var order in Xlsx.ReadAsync<Order>(stream))
{
    await db.Orders.AddAsync(order);
}

Note: IAsyncEnumerable reading streams rows as they're parsed from the ZIP/XWL, but the actual XML cell parsing is synchronous CPU work. The async benefit is primarily on the I/O side.

Real-World Benchmarks

All benchmarks run on an Apple M4 with .NET 10, comparing against MiniExcel, ClosedXML, EPPlus, and raw OpenXml SDK. The benchmark code is available in the companion repository.

10,000 rows × 4 string columns

Library	Mean	Allocated	Ratio
Magicodes.IE.IO	2.93 ms	979 KB	—
MiniExcel	11.91 ms	36,340 KB	37×
EPPlus	40.22 ms	29,560 KB	30×
ClosedXML	50.44 ms	84,396 KB	86×
OpenXml SDK	48.96 ms	28,596 KB	29×

10,000 rows × mixed types (string + number + datetime + bool)

Library	Mean	Allocated	Ratio
Magicodes.IE.IO	4.99 ms	1,158 KB	—
MiniExcel	12.97 ms	37,906 KB	33×
EPPlus	87.13 ms	38,400 KB	33×
ClosedXML	68.26 ms	102,309 KB	88×

Key takeaways

• Speed: 4× faster than MiniExcel, 8–10× faster than EPPlus/ClosedXML

• Memory: 30–100× less allocation than alternatives

• Gen2 GC: Minimal or zero Gen2 collections vs. competitors that trigger Gen2 on every iteration

The 37–88× allocation difference isn't a small optimization — it's the difference between a server that can handle thousands of concurrent exports and one that falls over under GC pressure.

When to Use Each Approach

Scenario	Recommendation
File export, known small data	Any library works; choose based on ease of use
Web API file download (HTTP stream)	Streaming approach — avoid materializing byte[]
Database → Excel (large datasets)	IAsyncEnumerable + WriteAsync — no full materialization
High-concurrency server export	Low-allocation streaming — minimize GC pauses
Complex formatting/charts/pivot tables	ClosedXML or EPPlus — they have richer formatting APIs
Read-only template generation	Streaming is ideal — you never need to mutate cells post-write

Limitations

No single approach fits all use cases. The streaming writer has known tradeoffs:

• No random access: Once a row is written, you can't go back and modify it. This is fine for export, not for interactive editing.

• Reader doesn't evaluate formulas: Read<T> reads cached values, not formula results.

• No ZIP64: The underlying ZIP writer doesn't support ZIP64 yet — files must fit within ZIP32 limits (4 GB raw, effectively ~2 GB compressed for large workbooks).

• Formatting is output-only: You specify styles declaratively; there's no DOM to programmatically modify after creation.

Conclusion

The streaming, low-allocation approach to OOXML generation is not inherently complex — it's just applying well-established .NET patterns (Span<T>, IBufferWriter<T>, IAsyncEnumerable<T>) to a problem that's traditionally been solved with DOM-style libraries. The result is an 8–10× speed improvement and 30–100× less memory allocation, without sacrificing the type safety and fluent API that .NET developers expect.

The techniques described here — direct-to-stream XML writing, IBufferWriter<byte> pooling, SST heuristics, and IAsyncEnumerable integration — are transferable to any XML-based format and serve as a general template for high-performance .NET I/O.

Best ASP.NET Core 10.0 Hosting Recommendation

One of the most important things when choosing a good ASP.NET Core 10.0 hosting is the feature and reliability. HostForLIFE is the leading provider of Windows hosting and affordable ASP.NET Core 10.0, their servers are optimized for PHP web applications. The performance and the uptime of the hosting service are excellent and the features of the web hosting plan are even greater than what many hosting providers ask you to pay for. 

At HostForLIFE, customers can also experience fast ASP.NET Core 10.0 hosting. The company invested a lot of money to ensure the best and fastest performance of the datacenters, servers, network and other facilities. Its datacenters are equipped with the top equipments like cooling system, fire detection, high speed Internet connection, and so on. That is why HostForLIFE guarantees 99.9% uptime for ASP.NET Core 10.0. And the engineers do regular maintenance and monitoring works to assure its Orchard hosting are security and always up.

Read More...

A Practical Comparison between Event Sourcing and CRUD Applications

Event Sourcing vs. CRUD Applications: A Practical Comparison Most commercial applications are based on the CRUD (Create, Read, Update, Delete) architecture. Whether you're creating an e-commerce platform, inventory management system, banking application, or customer portal, CRUD operations make it simple to handle data.

However, as systems expand in complexity, companies frequently want more than simply the present status of their data. They may require a comprehensive audit trail, historical reconstruction, event-driven workflows, or assistance with complicated business processes comparison.

This is where Event Sourcing becomes an alternative architectural approach.

Instead of storing only the current state of data, Event Sourcing stores every change as a sequence of events. The current state is then derived by replaying those events.

Both approaches are valuable, but they solve different problems. Understanding their strengths, limitations, and trade-offs is essential when designing modern applications.

In this article, we'll compare Event Sourcing and CRUD architectures, examine real-world scenarios, and discuss when each approach is the better choice.

Understanding CRUD Applications

CRUD is the most common application architecture.

The four operations are:

• Create

• Read

• Update

• Delete

Example:

Customer Record
       ↓
Create
       ↓
Update
       ↓
Delete

A database stores only the latest version of the data.

Consider a customer record.

Initial state:

{
  "id": 101,
  "name": "John Smith",
  "status": "Active"
}

JSON

After an update:

{
  "id": 101,
  "name": "John Smith",
  "status": "Premium"
}

JSON

The previous state is typically lost unless separate auditing mechanisms are implemented.

Understanding Event Sourcing

Event Sourcing stores every state change as an immutable event.

Instead of storing the current state:

Customer Created
Customer Activated
Customer Upgraded

The application reconstructs the current state by replaying all events.

Example:

Event 1:
CustomerCreated

Event 2:
CustomerActivated

Event 3:
CustomerUpgraded

Current state:

Replay Events
      ↓
Premium Customer

The entire history remains available permanently.

Core Architectural Difference

The primary difference lies in what gets stored.

CRUD

Stores current state.

Example:

Database
      ↓
Current Customer Record

Event Sourcing

Stores business events.

Example:

Event Store
      ↓
CustomerCreated
CustomerActivated
CustomerUpgraded

Current state becomes a derived representation rather than the primary source of truth.

Real-World Example: Bank Account

Consider a banking application.

CRUD Approach

Current record:

{
  "accountId": 1001,
  "balance": 1200
}

JSON

When money is deposited:

Balance = 1200

After deposit:

Balance = 1500

Only the latest balance exists.

Event Sourcing Approach

Events:

AccountOpened
DepositMade(1000)
DepositMade(500)
WithdrawalMade(300)

Current balance:

Replay Events
      ↓
1200

The complete transaction history is preserved automatically.

Data Storage Comparison

CRUD Storage

Customer Table
Order Table
Product Table

Data is updated directly.

Event Sourcing Storage

Event Store
      ↓
Business Events

Events are never modified or deleted.

This creates an immutable record of business activity.

Auditability

Audit requirements often influence architectural decisions.

CRUD

Requires additional auditing mechanisms.

Example:

Application
      ↓
Database
      ↓
Audit Table

Developers must explicitly capture changes.

Event Sourcing

Auditing is built into the architecture.

Example:

Every Event
      ↓
Permanent History

The audit trail exists automatically.

This is one of Event Sourcing's strongest advantages.

Handling Business History

Many systems need historical insights.

Questions such as:

• Who changed this record?

• When was it changed?

• What was the previous value?

CRUD

These answers may require:

• Audit tables

• Change tracking

• Log analysis

Event Sourcing

The answers already exist within the event stream.

Example:

Event Timeline
      ↓
Complete Business History

Historical analysis becomes significantly easier.

Integration with Event-Driven Systems

Modern architectures frequently use asynchronous communication.

Example:

Order Created
      ↓
Inventory Service

Order Created
      ↓
Shipping Service

Order Created
      ↓
Billing Service

CRUD

Additional mechanisms are often required to publish events.

Event Sourcing

Events already exist as part of the persistence model.

This makes integration with event-driven systems more natural.

Performance Considerations

Performance characteristics differ significantly.

CRUD Performance

Read operations are typically straightforward.

Example:

SELECT *
FROM Customers
WHERE Id = 101;

Current state is immediately available.

Event Sourcing Performance

State reconstruction may require replaying events.

Example:

1000 Events
      ↓
Rebuild State

To improve performance, systems often use snapshots.

Example:

Snapshot
      ↓
Recent Events
      ↓
Current State

This reduces replay overhead.

Complexity Comparison

CRUD

Advantages:

• Simple implementation

• Familiar design

• Broad tooling support

• Easy onboarding

Architecture:

Application
      ↓
Database

Event Sourcing

Advantages:

• Rich business history

• Built-in auditing

• Better event integration

Architecture:

Application
      ↓
Event Store
      ↓
Projections
      ↓
Read Models

Event Sourcing introduces additional complexity.

Common CRUD Use Cases

CRUD is often ideal for:

• Content management systems

• Inventory applications

• Internal business tools

• Administrative portals

• Standard web applications

Example:

Application
      ↓
Relational Database

The simplicity of CRUD is often sufficient.

Common Event Sourcing Use Cases

Event Sourcing is valuable when:

• Auditing is critical

• Business history matters

• Event-driven architectures are required

• Regulatory compliance is important

• Complex workflows exist

Examples:

• Banking systems

• Trading platforms

• Insurance systems

• Financial applications

• Logistics platforms

These domains often benefit from immutable event histories.

Can They Be Combined?

Yes.

Many modern systems use a hybrid approach.

Architecture:

CRUD Components
      ↓
Simple Workflows

Event Sourcing Components
      ↓
Critical Business Processes

Organizations often apply Event Sourcing only where its benefits justify the added complexity.

This approach balances maintainability and functionality.

Benefits of CRUD

Simplicity

Easy to understand and implement.

Mature Ecosystem

Supported by virtually every database platform.

Fast Development

Suitable for most business applications.

Efficient Reads

Current state is immediately available.

Benefits of Event Sourcing

Complete Audit Trail

Every change is permanently recorded.

Historical Reconstruction

Past states can be recreated.

Event-Driven Integration

Events naturally drive workflows.

Strong Domain Modeling

Business actions become first-class concepts.

These benefits make Event Sourcing attractive for complex domains.

Best Practices

When choosing between CRUD and Event Sourcing, consider the following recommendations.

Start with Business Requirements

Do not adopt Event Sourcing simply because it is popular.

Use CRUD for Simpler Systems

Most applications do not require full event histories.

Use Event Sourcing for High-Audit Domains

Regulated industries often benefit significantly.

Consider Operational Complexity

Event Sourcing requires additional infrastructure and expertise.

Evaluate Long-Term Needs

Future reporting, analytics, and compliance requirements may influence the decision.

Architectural choices should support business goals rather than technology trends.

Conclusion

CRUD and Event Sourcing are fundamentally distinct techniques to handling application data. CRUD focuses on storing and updating current information, making it simple, efficient, and appropriate for the vast majority of business applications. Its simple design and robust ecosystem make it the go-to solution for many development teams.

Event Sourcing, on the other hand, views business events as the source of truth. By preserving every modification as an immutable event, it gives a comprehensive history of system activity, makes auditing easier, and interacts well with event-driven systems. However, these advantages are accompanied with greater complexity and operational costs.

Best ASP.NET Core 10.0 Hosting Recommendation

One of the most important things when choosing a good ASP.NET Core 10.0 hosting is the feature and reliability. HostForLIFE is the leading provider of Windows hosting and affordable ASP.NET Core, their servers are optimized for PHP web applications. The performance and the uptime of the hosting service are excellent and the features of the web hosting plan are even greater than what many hosting providers ask you to pay for. 

At HostForLIFEASP.NET, customers can also experience fast ASP.NET Core hosting. The company invested a lot of money to ensure the best and fastest performance of the datacenters, servers, network and other facilities. Its datacenters are equipped with the top equipments like cooling system, fire detection, high speed Internet connection, and so on. That is why HostForLIFEASP.NET guarantees 99.9% uptime for ASP.NET Core. And the engineers do regular maintenance and monitoring works to assure its Orchard hosting are security and always up.

Read More...