DEV Community: Ahmed Omeiza

CORS Explained: Why Your Browser Blocks Your API

Ahmed Omeiza — Fri, 25 Sep 2026 12:17:44 +0000

You build an API.

Your frontend sends a request.

The API responds successfully.

And somehow, the browser still says:

Blocked by CORS policy.

What just happened?

Let's break it down.

What Is CORS?

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls whether a web page can make requests to a different origin.

An origin is made up of:

Protocol
Domain
Port

For example:

http://localhost:3000

and

http://localhost:5000

are different origins because their ports are different.

So if your React application runs on:

http://localhost:3000

and your ASP.NET API runs on:

http://localhost:5000

the browser treats the request as cross-origin.

Why Does CORS Exist?

Imagine a user is logged into their banking website.

Now imagine another website could freely make requests to that banking API using the user's browser.

That could create serious security problems.

The browser therefore follows the same-origin policy by default.

CORS provides a controlled way for servers to say:

"Requests from this particular origin are allowed."

A Simple Example

Suppose your frontend does this:

fetch("https://api.example.com/users")

But your frontend is running on:

https://app.example.com

The browser sees two different origins:

Frontend:
https://app.example.com

API:
https://api.example.com

The API needs to explicitly allow the frontend's origin.

A server might respond with:

Access-Control-Allow-Origin: https://app.example.com

The browser sees this header and knows that the frontend is allowed to access the response.

CORS in ASP.NET Core

In ASP.NET Core, you can configure CORS using a policy.

For example:

builder.Services.AddCors(options =>
{
    options.AddPolicy("FrontendPolicy", policy =>
    {
        policy
            .WithOrigins("https://app.example.com")
            .AllowAnyHeader()
            .AllowAnyMethod();
    });
});

Then apply the policy:

app.UseCors("FrontendPolicy");

Now the API allows requests from:

https://app.example.com

What About `AllowAnyOrigin()`?

You might see this:

policy
    .AllowAnyOrigin()
    .AllowAnyHeader()
    .AllowAnyMethod();

This means requests from any origin can access the API's CORS-enabled responses.

It's convenient during development, but you should be deliberate about using it in production.

If your application only needs to communicate with one frontend, explicitly specify that origin:

.WithOrigins("https://app.example.com")

What Is a Preflight Request?

Sometimes the browser sends an OPTIONS request before the actual request.

This is called a preflight request.

For example, your frontend wants to send:

POST /api/users
Authorization: Bearer ...
Content-Type: application/json

The browser may first ask the server:

OPTIONS /api/users

with headers describing the intended request.

The server responds with something like:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Authorization, Content-Type

If the browser is satisfied with the response, it sends the actual POST request.

So when debugging CORS, don't only look at the request you expected. Check whether an OPTIONS request is failing first.

CORS Is a Browser Restriction

This is one of the most important things to understand.

CORS is primarily enforced by browsers.

For example:

React → Browser → API

The browser checks the CORS rules.

But if you make the same request using:

Postman → API

you may not see the same CORS error.

That's because Postman isn't enforcing browser CORS rules in the same way.

So:

"It works in Postman but not in my frontend"

is often a strong clue that you're dealing with CORS.

CORS ≠ Authentication

CORS doesn't determine whether a user is authenticated.

These are different concerns.

Authentication asks:

Who are you?

Authorization asks:

Are you allowed to access this resource?

CORS asks:

Is this browser-based origin allowed to access the response?

For example, your API can correctly validate a JWT and still reject the browser's access because the CORS configuration doesn't allow the frontend's origin.

A Common Mistake

Developers sometimes see:

CORS error

and immediately add:

.AllowAnyOrigin()

That may hide the immediate problem, but it doesn't necessarily explain what caused it.

Instead, check:

Is the frontend origin correct?
Is the API returning the correct CORS headers?
Is the OPTIONS preflight succeeding?
Are the required headers allowed?
Are the required HTTP methods allowed?
Is middleware configured in the correct order?

Understanding the request flow is much more useful than simply disabling the restriction.

Key Takeaway

CORS isn't your API randomly refusing requests.

It's the browser enforcing a security boundary between different origins.

Once you understand origin, same-origin policy, preflight requests, and CORS response headers, those confusing:

Blocked by CORS policy

errors become much easier to debug.

Don't just add AllowAnyOrigin() because the error disappeared. Understand why the browser rejected the request in the first place.

Webhooks vs Polling: How Should Your Systems Communicate?

Ahmed Omeiza — Thu, 24 Sep 2026 09:43:04 +0000

Your application needs to know when something happens.

A payment succeeds.
An order is shipped.
A GitHub issue is created.

The question is: should your application keep asking for updates, or should the other system notify you when something happens?

That’s the difference between polling and webhooks.

Polling: “Has anything happened yet?”

With polling, your application repeatedly asks another system for updates.

For example:

GET /api/payment/123

Your application might make this request every 5 seconds:

Is the payment complete?
    ↓
    No
    ↓
Wait 5 seconds
    ↓
Is the payment complete?
    ↓
    No
    ↓
Wait 5 seconds
    ↓
Is the payment complete?

Eventually, the payment changes to successful.

The problem

Most of those requests may return the same answer.

If you have thousands of users doing this, you're generating a lot of unnecessary requests.

Polling is simple, but it can be wasteful.

Webhooks: “I’ll tell you when it happens.”

With a webhook, the receiving application provides an endpoint that another system can call when an event occurs.

For example:

POST /webhooks/payment

When the payment succeeds, the payment provider sends:

{
  "event": "payment.success",
  "paymentId": "123",
  "amount": 50000
}

Instead of asking repeatedly:

“Did the payment succeed?”

Your application gets notified:

“The payment succeeded.”

This is an event-driven approach.

Webhooks vs Polling

	Polling	Webhooks
Communication	Client asks repeatedly	Server sends event
Timing	Based on polling interval	Usually near real-time
Requests	Can generate many unnecessary requests	Only sends when an event occurs
Complexity	Simpler to implement	Requires webhook endpoint
Reliability	Easy to retry requests	Requires handling retries/duplicates
Best for	Periodic checks	Event-driven updates

When should you use polling?

Polling makes sense when:

The external system doesn't support webhooks.
You need to periodically synchronize data.
You don't need real-time updates.
You want a simple implementation.

For example, your application might check an external API every 10 minutes for new records.

When should you use webhooks?

Webhooks are useful when you need to react to events quickly.

Common examples include:

Payment notifications
Order status changes
GitHub events
Email delivery events
Subscription changes
CI/CD events

For example:

Customer pays
     ↓
Payment provider
     ↓
Webhook
     ↓
Your API
     ↓
Update order
     ↓
Send confirmation

No constant checking required.

One important webhook problem

Webhooks aren't automatically reliable just because they're event-driven.

The sender might retry an event if your server doesn't respond successfully.

That means you could receive the same webhook more than once.

Your application should therefore handle idempotency.

For example:

payment.success
payment.success
payment.success

Your system should still process the payment only once.

A common approach is to store the webhook's unique event ID and ignore events that have already been processed.

You should also verify webhook signatures so that arbitrary clients can't impersonate the service sending your events.

The key takeaway

Polling asks, “Has anything changed?”

Webhooks say, “Something changed.”

If you need periodic synchronization or the external service doesn't provide events, polling can be perfectly reasonable.

But when you're reacting to well-defined events, webhooks can reduce unnecessary requests and provide a much more responsive architecture.

Choose based on the communication pattern your system actually needs—not simply because one approach sounds more modern.

Cursor Pagination vs Offset Pagination: Which One Should You Use?

Ahmed Omeiza — Wed, 23 Sep 2026 13:40:48 +0000

Pagination looks simple until your dataset gets large.

At first, page=2&limit=20 seems perfectly fine. But as your application grows, pagination strategy can start affecting query performance, consistency, and user experience.

Two common approaches are offset pagination and cursor pagination.

Let’s break down how they work and when to use each.

Offset Pagination

Offset pagination works by telling the database:

Skip these records and give me the next batch.

For example:

GET /api/products?page=3&limit=20

The database might translate this into:

SELECT *
FROM Products
ORDER BY Id
OFFSET 40 ROWS
FETCH NEXT 20 ROWS ONLY;

The first page skips 0 records, the second skips 20, and the third skips 40.

The problem with large offsets

As the offset gets larger, the database may have to scan and skip a lot of rows before returning the records you actually want.

Imagine requesting:

GET /api/products?page=50000&limit=20

The database potentially has to work through a huge number of records before returning just 20.

This can become expensive with large datasets.

There is another problem: changing data.

Imagine you're viewing page 2 while new records are inserted at the beginning of the dataset.

Records can shift between pages, meaning you might:

See the same record twice
Miss a record
Get inconsistent results between requests

Cursor Pagination

Cursor pagination takes a different approach.

Instead of saying:

Skip 40 records.

You say:

Give me the records after this specific position.

For example:

GET /api/products?limit=20&cursor=eyJpZCI6NDA...

The cursor represents a position in the dataset.

A simplified query could look like:

SELECT *
FROM Products
WHERE Id > 40
ORDER BY Id
LIMIT 20;

The response might contain:

{
  "data": [
    // 20 products
  ],
  "nextCursor": "eyJpZCI6NjA..."
}

The client uses nextCursor to request the next batch.

GET /api/products?limit=20&cursor=eyJpZCI6NjA...

The database can efficiently find records after the cursor, especially when the ordering column is properly indexed.

The Key Difference

The simplest way to remember it:

Offset pagination asks:

"How many records should I skip?"

Cursor pagination asks:

"Where should I continue from?"

That difference becomes important as your dataset grows.

	Offset	Cursor
Simple to implement	✅	⚠️
Jump directly to page 50	✅	❌
Good for large datasets	⚠️	✅
Handles changing datasets well	⚠️	✅
Works well for infinite scrolling	⚠️	✅
Requires a stable ordering	Yes	Yes
Easy page numbers	✅	❌

When Should You Use Offset Pagination?

Offset pagination is often a good choice for:

Admin dashboards
Search results
Small-to-medium datasets
Interfaces where users need page numbers
Applications where jumping to a specific page matters

For example:

GET /api/users?page=5&limit=25

It's simple, familiar, and often perfectly adequate.

Don't introduce cursor pagination just because your application uses a database.

When Should You Use Cursor Pagination?

Cursor pagination becomes more useful when:

Your dataset is large
Data changes frequently
You're building infinite scrolling
You're building feeds or timelines
Consistent traversal matters
You need efficient pagination deep into a dataset

For example, social media feeds are a natural fit.

Instead of asking:

Give me page 50.

The client asks:

Give me the next 20 posts after this cursor.

One Important Detail: Your Cursor Needs an Order

Cursor pagination isn't simply:

WHERE Id > cursor

and you're done.

Your ordering needs to be stable and deterministic.

For example, if you're ordering by:

CreatedAt DESC

multiple records could have the same timestamp.

A common solution is using a combination such as:

ORDER BY CreatedAt DESC, Id DESC

The cursor can then contain both values:

{
  "createdAt": "2026-09-23T12:30:00Z",
  "id": 4821
}

This gives the database an unambiguous position to continue from.

In production systems, cursors are also commonly encoded or signed so clients don't have to manipulate internal pagination values directly.

So Which Should You Choose?

Don't choose based on which one sounds more advanced.

Choose based on the requirements of your application.

If you need simple page navigation, offset pagination may be enough.

If you need efficient traversal through a large, frequently changing dataset, cursor pagination is often a better fit.

Key Takeaway

Offset pagination is about pages. Cursor pagination is about position.

Offset pagination is simpler and gives you familiar page-based navigation.

Cursor pagination requires more thought, but it can provide more consistent and efficient traversal as your dataset grows.

The best pagination strategy isn't the most sophisticated one.

It's the one that fits the way your users actually consume your data.

HTTP/1.1 vs HTTP/2 vs HTTP/3: What Actually Changed?

Ahmed Omeiza — Tue, 22 Sep 2026 13:11:19 +0000

HTTP started simple:

Client sends a request. Server sends a response.

But modern applications don't make just one request.

A typical web page might load dozens or hundreds of resources — APIs, images, JavaScript, CSS, fonts, and more.

That is where HTTP/1.1 started showing its age.

HTTP/2 improved things significantly. HTTP/3 changed the underlying transport completely.

Let's break down what actually changed.

HTTP/1.1: Simple, But Sequential

HTTP/1.1 uses TCP and traditionally processes requests in a way that can cause head-of-line blocking.

Imagine this:

Request 1 ────────> Response 1
Request 2 ────────────────> Response 2
Request 3 ─────────────────────> Response 3

If Request 1 is delayed, other requests can be affected.

Browsers worked around this by opening multiple TCP connections, but that came with additional overhead.

HTTP/1.1 also introduced useful features such as:

Persistent connections
Chunked transfer encoding
Better caching mechanisms
Pipelining support, although it was rarely used effectively

It worked — but the web had become much more demanding.

HTTP/2: Multiple Requests Over One Connection

HTTP/2 kept TCP but changed how HTTP messages are transferred.

The biggest improvement?

Multiplexing.

Instead of waiting for one request to finish before processing another, multiple streams can share the same TCP connection.

             ┌── Request 1
             ├── Request 2
TCP ─────────┼── Request 3
             ├── Request 4
             └── Request 5

This reduces the need for multiple connections and makes it much more efficient to load many resources.

Binary Instead of Text

HTTP/1.1 messages are text-based.

HTTP/2 uses a binary framing layer.

That allows the protocol to break requests and responses into smaller frames and efficiently interleave them.

Header Compression

HTTP/2 introduced HPACK.

Instead of repeatedly sending the same HTTP headers, connections can compress and reuse header information.

Server Push

HTTP/2 also introduced server push, allowing servers to send resources before the client explicitly requested them.

However, browser support and real-world usefulness were limited, and server push has since been removed from modern browser implementations.

HTTP/3: HTTP Over QUIC

HTTP/3 makes the biggest architectural change.

Instead of:

HTTP → TCP → IP

HTTP/3 uses:

HTTP/3 → QUIC → UDP → IP

Don't let the use of UDP fool you.

QUIC provides the reliability, ordering, congestion control, and security mechanisms needed for HTTP traffic.

And it does this at the transport layer.

The Big Difference: Head-of-Line Blocking

Here's where HTTP/3 becomes particularly interesting.

With HTTP/2, multiple streams share one TCP connection.

If a TCP packet is lost, TCP needs to retransmit it before the affected data can be delivered.

That can cause transport-level head-of-line blocking.

HTTP/3's QUIC uses independent streams.

HTTP/2

TCP Connection
├── Stream 1 ── X
├── Stream 2 ── X
└── Stream 3 ── X

Packet loss can affect the connection's delivery.

HTTP/3

QUIC Connection
├── Stream 1 ── X
├── Stream 2 ── ✓
└── Stream 3 ── ✓

Other streams can continue progressing.

That's especially useful on networks where packet loss is common.

Connection Establishment

HTTP/3 also improves connection setup.

QUIC integrates TLS 1.3 into the protocol.

This reduces the number of round trips required to establish a secure connection compared with traditional TCP + TLS setup.

QUIC also supports connection migration.

For example, if your device moves from Wi-Fi to mobile data, a QUIC connection can potentially continue without establishing an entirely new connection.

HTTP/1.1 vs HTTP/2 vs HTTP/3

Feature	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP	QUIC over UDP
Multiplexing	Limited	Yes	Yes
Binary framing	No	Yes	Yes
Header compression	—	HPACK	QPACK
Transport HOL blocking	Yes	Yes	No
TLS	Separate	Separate	Built into QUIC
Connection migration	No	No	Yes

The important thing isn't memorizing the table.

It's understanding the progression:

HTTP/1.1
   ↓
Multiple connections

HTTP/2
   ↓
Multiplexing over TCP

HTTP/3
   ↓
Multiplexing over QUIC

What Should Developers Care About?

You usually don't implement HTTP/2 or HTTP/3 yourself.

Your web server, reverse proxy, CDN, browser, and networking stack handle most of the protocol details.

As a backend developer, what's important is understanding the implications.

For example, if you're building an API:

Client
   ↓
HTTP/3
   ↓
CDN / Reverse Proxy
   ↓
ASP.NET Core API
   ↓
Database

Your application code can remain largely the same while the underlying HTTP protocol changes how efficiently requests travel across the network.

The Key Takeaway

HTTP/1.1 made the modern web possible.

HTTP/2 made multiple requests much more efficient through multiplexing.

HTTP/3 takes that further by moving HTTP onto QUIC, reducing the impact of packet loss and improving connection establishment and migration.

So don't think of HTTP/3 as simply:

"HTTP/2 but faster."

It's a fundamental change in how HTTP communicates over the network.

HTTP/1.1 optimized connections.
HTTP/2 optimized streams.
HTTP/3 optimized the transport underneath them.

OpenTelemetry in .NET: Stop Guessing What Your Application Is Doing

Ahmed Omeiza — Mon, 21 Sep 2026 15:13:25 +0000

Your API is slow.

But why?

Is the database taking too long?
Is another service failing?
Is an external API responding slowly?

Logs can give you clues, but when you're dealing with a distributed application, logs alone can make debugging painful.

This is where OpenTelemetry comes in.

What is OpenTelemetry?

OpenTelemetry (OTel) is an open-source observability framework for collecting telemetry data from your applications.

It focuses mainly on three types of data:

Traces — What happened during a request?
Metrics — How is the application performing?
Logs — What events are happening?

The goal is simple:

Understand what your application is doing without guessing.

Why Does This Matter in .NET?

Imagine a request going through your application:

Client
  ↓
ASP.NET Core API
  ↓
Order Service
  ↓
Payment Service
  ↓
Database

The user only sees:

Request took 3.2 seconds

But where did those 3.2 seconds go?

OpenTelemetry can give you a trace like:

HTTP Request          3.2s
 ├── Order Service    1.1s
 ├── Payment API      1.7s
 └── Database         0.4s

Now you have something useful.

Instead of saying:

"The API is slow."

You can say:

"The Payment API is responsible for most of the request latency."

That's the difference between logging events and understanding system behavior.

Traces: Following a Request

A trace represents the journey of a request through your system.

Each operation within that journey is represented as a span.

For example:

Trace
│
├── HTTP GET /orders
│
├── SQL Query
│
└── HTTP POST /payments

Each span can contain information such as:

Duration
Operation name
Status
Attributes
Errors
Relationships to other spans

The important part is that these spans can be connected together into one trace.

Metrics: Measuring Performance

Metrics give you numbers about your application.

For example:

HTTP Requests:       15,420
Request Errors:          73
Average Duration:      180ms
Active Requests:          12

Metrics are useful when you want to answer questions like:

"Are errors increasing?"

or:

"Has API latency gotten worse?"

Logs: Understanding Events

Logs record events happening inside your application.

For example:

Order 4821 created
Payment request started
Payment failed

OpenTelemetry can also help correlate logs with traces.

That means you can go from:

Trace → Span → Log

and understand what happened during a specific request.

Setting Up OpenTelemetry in ASP.NET Core

Install the required packages:

dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol
dotnet add package OpenTelemetry.Instrumentation.AspNetCore
dotnet add package OpenTelemetry.Instrumentation.Http
dotnet add package OpenTelemetry.Instrumentation.Runtime

Then configure OpenTelemetry in Program.cs:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing =>
    {
        tracing
            .AddAspNetCoreInstrumentation()
            .AddHttpClientInstrumentation()
            .AddOtlpExporter();
    })
    .WithMetrics(metrics =>
    {
        metrics
            .AddAspNetCoreInstrumentation()
            .AddRuntimeInstrumentation()
            .AddOtlpExporter();
    });

Now your application can automatically collect telemetry from common ASP.NET Core and HTTP operations.

Where Does the Data Go?

OpenTelemetry doesn't try to be your dashboard.

Instead, it collects and exports telemetry to an observability backend.

A common architecture looks like this:

.NET Application
       │
       ▼
 OpenTelemetry
       │
       ▼
   OTLP Exporter
       │
       ▼
Observability Backend
       │
       ▼
    Dashboard

You can use tools such as Grafana, Jaeger, Zipkin, or other systems that support OpenTelemetry.

This separation is important.

Your application produces telemetry.

Your observability platform stores, analyzes, and visualizes it.

Automatic vs Manual Instrumentation

OpenTelemetry can automatically instrument many common operations.

For example:

.AddAspNetCoreInstrumentation()
.AddHttpClientInstrumentation()

This can give you useful telemetry without manually creating spans for every request.

But sometimes you want to track your own business operations.

For example:

using var activity = ActivitySource.StartActivity("ProcessOrder");

activity?.SetTag("order.id", orderId);
activity?.SetTag("customer.id", customerId);

Now you have a custom span representing your business operation.

This becomes useful when infrastructure-level telemetry isn't enough to understand your application's behavior.

OpenTelemetry Is Not Just Logging

This is one of the most important distinctions.

Traditional logging might tell you:

Payment failed for order 4821

A trace can tell you:

Request
  ↓
Create Order
  ↓
Database Query       120ms
  ↓
Payment API          1.8s
  ↓
Payment Failed

The second gives you context.

That's why observability becomes increasingly important as applications become distributed.

The Key Takeaway

OpenTelemetry gives your .NET applications a standardized way to collect traces, metrics, and logs.

Instead of asking:

"Why is this request slow?"

you can investigate the actual path the request took.

For a small application, you might get away with logs.

For a system with multiple services, databases, queues, and external APIs, observability becomes much harder to ignore.

Don't just collect logs. Understand the journey of your requests.

Rate Limiting: The Traffic Cop Your API Needs

Ahmed Omeiza — Sun, 20 Sep 2026 12:51:44 +0000

Your API can be perfectly designed and still fail when too many requests hit it at once.

That’s where rate limiting comes in.

Rate limiting controls how many requests a client can make to your API within a specific period.

For example:

A user can make 100 requests per minute.

Request #101? They have to wait.

Why Do We Need Rate Limiting?

Without rate limiting, a single client could send thousands of requests to your API and consume resources that should be available to everyone else.

Rate limiting helps protect against:

Abuse and spam
Brute-force attacks
Accidental request floods
Resource exhaustion
Excessive API usage

It also helps keep your API predictable under heavy traffic.

A Simple Example

Imagine you have:

GET /api/products

You configure a limit of:

100 requests / minute / client

A client makes 100 requests within the minute.

The next request could receive:

429 Too Many Requests

The API is basically saying:

"Slow down. You've reached your limit."

How Does Rate Limiting Know Who to Limit?

The limit can be applied based on different identifiers:

IP address

192.168.1.20 → 100 requests/minute

Useful for controlling anonymous traffic.

User

User 123 → 1,000 requests/hour

Useful when users are authenticated.

API key

API_KEY_ABC → 10,000 requests/day

Common for public APIs and third-party integrations.

Common Rate-Limiting Algorithms

There are several ways to implement rate limiting.

Fixed Window

Requests are counted within fixed time periods.

12:00 - 12:01 → 100 requests
12:01 - 12:02 → 100 requests

Simple, but traffic can spike around the boundary between windows.

Sliding Window

Instead of using fixed time blocks, the system looks at a continuously moving time window.

This provides more accurate control over request bursts.

Token Bucket

The system maintains a bucket of tokens.

Each request consumes a token.

Tokens are continuously added back at a fixed rate.

This allows controlled bursts while still enforcing an average request rate.

Rate Limiting in ASP.NET Core

ASP.NET Core provides built-in rate-limiting middleware.

For example:

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("fixed", limiterOptions =>
    {
        limiterOptions.PermitLimit = 100;
        limiterOptions.Window = TimeSpan.FromMinutes(1);
    });
});

Then enable it in the request pipeline:

app.UseRateLimiter();

You can also apply a policy to specific endpoints instead of limiting your entire API.

Rate Limiting vs Authentication

These solve different problems.

Authentication asks:

"Who are you?"

Rate limiting asks:

"How many requests are you allowed to make?"

An authenticated user can still abuse an API, so authentication does not replace rate limiting.

The Key Takeaway

Rate limiting isn't just about blocking excessive requests.

It's about protecting your API, controlling resource usage, and making sure one client doesn't negatively affect everyone else.

If your API is exposed to the internet, don't just ask:

"Can users access this endpoint?"

Also ask:

"How often should they be allowed to access it?"

Process vs Thread: What’s Really Running Your Application?

Ahmed Omeiza — Sat, 19 Sep 2026 07:24:26 +0000

When your application is running, it isn’t just “executing code.”

The operating system is managing processes and threads behind the scenes.

Understanding the difference matters because it affects performance, memory usage, concurrency, and how applications communicate.

What Is a Process?

A process is a running instance of a program.

For example, when you open Chrome, your operating system creates one or more processes to run it.

A process has its own:

Memory space
Resources
File handles
Security context
Threads

Think of a process as a house.

The house has its own resources and is separated from other houses.

Process A
├── Memory
├── Resources
└── Threads

If Process A crashes, Process B generally isn't directly affected because they have separate memory spaces.

What Is a Thread?

A thread is an execution path inside a process.

A process can contain multiple threads that execute work concurrently.

Process
├── Thread 1
├── Thread 2
└── Thread 3

Using the house analogy:

A process is the house.
Threads are the people working inside it.

They share the house's resources, but each person can work on a different task.

The Biggest Difference

The most important difference is memory.

Processes have separate memory spaces.

Threads within the same process share memory.

Process A                 Process B
┌───────────────┐         ┌───────────────┐
│ Shared by     │         │ Shared by     │
│ its threads   │         │ its threads   │
│               │         │               │
│ Thread 1      │         │ Thread 1      │
│ Thread 2      │         │ Thread 2      │
└───────────────┘         └───────────────┘

Threads in Process A cannot simply access Process B's memory.

But Thread 1 and Thread 2 inside Process A can access the same process memory.

That's useful for communication, but it also introduces problems such as race conditions and the need for synchronization.

Process vs Thread

Process	Thread
Independent running program	Execution unit inside a process
Has its own memory space	Shares process memory
More expensive to create	Cheaper to create
Communication is more involved	Communication is easier
Better isolation	Less isolation
Can contain multiple threads	Belongs to a process

A Practical Example

Imagine a web server receiving requests.

Instead of processing everything sequentially:

Request 1 → Process
Request 2 → Process
Request 3 → Process

A process can use multiple threads:

Web Server Process
├── Thread 1 → Request 1
├── Thread 2 → Request 2
└── Thread 3 → Request 3

Now multiple pieces of work can be handled concurrently.

Modern applications often go further and use thread pools, asynchronous programming, processes, or a combination of these rather than manually creating a new thread for every request.

What Happens When a Thread Crashes?

This is another important distinction.

A problem in one thread can potentially affect the entire process because threads share the process's resources.

A process provides stronger isolation.

For example:

Process A              Process B
   │                      │
 Thread 1              Thread 1
 Thread 2              Thread 2
   │
   X Crash

A failure in Process A doesn't automatically mean Process B crashes.

That's one reason operating systems use processes as an important isolation boundary.

When Should You Think About Processes vs Threads?

Think about processes when isolation and independent resources matter.

Think about threads when multiple tasks need to execute within the same application and share data efficiently.

But in modern development, you usually won't manually choose between them for every task.

Frameworks and runtimes such as .NET provide abstractions like:

Task
async/await
ThreadPool
Background services

These allow you to handle concurrent work without manually managing every operating-system thread.

Key Takeaway

A process is an isolated running program with its own memory space.

A thread is an execution unit inside a process that shares the process's memory.

The simplest way to remember it:

Process = container. Thread = worker inside the container.

Once you understand that relationship, concepts like concurrency, parallelism, thread safety, synchronization, and async programming become much easier to reason about.

YAML vs JSON: Same Data, Different Trade-offs

Ahmed Omeiza — Fri, 18 Sep 2026 10:28:35 +0000

Your application doesn't care whether the configuration is YAML or JSON. But you might.

Both YAML and JSON are popular formats for representing structured data. You'll see them everywhere in modern development — from API responses and configuration files to Docker and CI/CD pipelines.

So, what's the actual difference?

JSON: Simple and Strict

JSON stands for JavaScript Object Notation.

It uses a strict syntax based on objects, arrays, keys, and values.

{
  "name": "Omeiza",
  "role": "Backend Developer",
  "skills": ["ASP.NET Core", "MySQL", "Redis"]
}

JSON is:

Strictly structured
Easy for machines to parse
Widely supported across programming languages
Commonly used for APIs and data exchange

The downside?

JSON can become difficult to read when the structure gets large.

YAML: Designed for Humans

YAML stands for YAML Ain't Markup Language.

It represents the same kind of structured data but uses indentation instead of brackets and braces.

name: Omeiza
role: Backend Developer
skills:
  - ASP.NET Core
  - MySQL
  - Redis

Notice how much cleaner it looks.

YAML is especially popular for configuration files, where developers frequently need to read and modify the data manually.

YAML vs JSON

1. Readability

YAML → Easier for humans to read.

JSON → More verbose because of {}, [], commas, and quotes.

2. Syntax

YAML → Uses indentation.

server:
  host: localhost
  port: 5000

JSON → Uses braces and brackets.

{
  "server": {
    "host": "localhost",
    "port": 5000
  }
}

YAML looks cleaner, but its indentation-based syntax also means formatting mistakes can cause problems.

3. APIs and Data Exchange

JSON is generally the natural choice for APIs.

For example:

GET /api/users/1

{
  "id": 1,
  "name": "Omeiza"
}

It's widely supported and predictable, making it a strong fit for communication between applications.

4. Configuration

YAML is frequently used for configuration.

You'll commonly encounter it in tools such as Kubernetes and CI/CD systems.

services:
  api:
    port: 5000
    environment:
      - Production

The hierarchical structure makes configuration easier to scan and edit.

5. Strictness

JSON is stricter.

That can be a good thing because invalid syntax is usually easier to identify.

YAML is more flexible, but that flexibility can introduce subtle issues around indentation, data types, and special characters.

So, Which One Should You Use?

It depends on the job.

Use JSON when:

You're building APIs.
You're exchanging data between applications.
You want strict, predictable syntax.
Your tooling already expects JSON.

Use YAML when:

You're writing configuration files.
Humans will frequently edit the file.
You're working with Kubernetes or CI/CD configuration.
Readability is a major concern.

The Important Lesson

YAML and JSON aren't really competing to replace each other.

They solve similar problems but excel in different situations.

JSON prioritizes strict structure and interoperability.

YAML prioritizes human readability and configuration.

The best choice isn't about which format is "better."

It's about who is consuming the data and what the data is being used for.

Monolith vs Microservices: When Should You Split Your Application?

Ahmed Omeiza — Thu, 17 Sep 2026 07:14:58 +0000

Not every application needs microservices. Sometimes, a well-built monolith is exactly what you need.

Microservices have become a popular architecture choice, especially in discussions about scalability and distributed systems.

But there's a common misconception:

Microservices are not automatically better than a monolith.

The right choice depends on the complexity, team, scale, and requirements of your application.

What Is a Monolith?

A monolithic application is built and deployed as a single unit.

For example, imagine an e-commerce application with:

User authentication
Products
Orders
Payments
Notifications

In a monolith, all of these might exist inside the same application and typically share the same deployment and infrastructure.

                E-Commerce App
                     |
        -----------------------------
        |       |       |      |     |
      Users  Products Orders Payments Notifications

This doesn't mean the code has to be messy.

A monolith can still use clean architecture, separation of concerns, dependency injection, modules, and well-defined boundaries.

Why Start With a Monolith?

It's simpler.

You have:

One application to deploy
One codebase to manage
Easier local development
Simpler debugging
Simpler communication between components
Usually less infrastructure overhead

For a small team building an early-stage product, this simplicity can be extremely valuable.

What Are Microservices?

Microservices split an application into smaller, independently deployable services.

Using the same e-commerce example:

             API Gateway
                  |
      -------------------------
      |        |       |      |
    Users   Orders  Payments Products
      |        |       |      |
     DB       DB      DB      DB

Each service is responsible for a specific business capability.

The Order Service handles orders.

The Payment Service handles payments.

The Product Service handles products.

They communicate over the network, commonly through HTTP APIs or messaging systems.

The important part is independent ownership and deployment, not simply having many projects.

The Real Difference

The biggest difference isn't:

"One has many services and the other has one."

It's about boundaries and deployment.

With a monolith:

Code → Build → Deploy

With microservices:

User Service   → Build → Deploy
Order Service  → Build → Deploy
Payment Service → Build → Deploy

A change to the Order Service doesn't necessarily require deploying the Payment Service.

That independence is one of the major benefits of microservices.

Monolith vs Microservices

Monolith	Microservices
Single deployable application	Multiple independently deployable services
Simpler infrastructure	More infrastructure
Easier to develop initially	More operational complexity
Easier debugging	Distributed debugging
Usually simpler communication	Network communication between services
Scaling is often application-wide	Services can scale independently
Simpler deployment	More complex deployment
Good for smaller systems/teams	Useful for larger, complex systems

Neither architecture is universally better.

They solve different problems.

The Hidden Cost of Microservices

Here's something developers sometimes underestimate:

Microservices move complexity; they don't remove it.

Instead of dealing with complexity inside one application, you now have to deal with:

Network failures
Service discovery
Distributed logging
Message queues
Authentication between services
Monitoring and tracing
Data consistency
Deployment orchestration
API versioning

For example, in a monolith:

Order → Payment

might simply be a method call.

In microservices:

Order Service
      |
      | HTTP / Message
      ↓
Payment Service

Now the network can fail.

The Payment Service can be unavailable.

The request can timeout.

You may need retries, idempotency, circuit breakers, distributed tracing, and better observability.

That's a very different level of complexity.

When Does Microservices Make Sense?

Microservices become more attractive when your system and organization have real reasons to need them.

For example:

Independent scaling

Suppose your product service receives 10x more traffic than your notification service.

With microservices, you can scale the Product Service independently.

Independent deployments

If the payment team needs to release a change, they don't necessarily need to deploy the entire application.

Large teams

Different teams can own different services with clear boundaries.

Different technology requirements

One service might benefit from .NET while another uses Python or Go.

Microservices can accommodate this when there's a genuine reason for doing so.

A Practical Example

Imagine you're building a URL shortener.

You could start with:

UrlShortener
├── Authentication
├── Short URLs
├── Redirects
├── Analytics
└── Admin

That's perfectly reasonable as a monolith.

As the system grows, you might eventually separate responsibilities:

                API Gateway
                     |
       ------------------------------
       |             |              |
   Auth Service   URL Service   Analytics Service

But don't split everything on day one just because microservices are popular.

Start with clear boundaries inside your application.

If you later need to extract a service, those boundaries make the transition much easier.

A Monolith Can Still Be Well Architected

This is important.

Monolith does not mean bad architecture.

You can build a modular monolith where different business domains are separated internally:

Application
├── Identity
├── Orders
├── Payments
├── Products
└── Notifications

Each module has clear responsibilities and dependencies.

This gives you many benefits of good separation without immediately introducing distributed-system complexity.

And if one module eventually needs to become its own service, you already have a logical boundary to work with.

So Which Should You Choose?

Instead of asking:

"Should I use microservices?"

Ask:

"What problem am I trying to solve?"

If your application is small and your team is small, a monolith may provide the simplicity you need.

If your system has genuinely independent domains, large teams, independent scaling requirements, or deployment needs, microservices may make sense.

Architecture should respond to real problems, not trends.

Key Takeaway

Start simple.

A monolith is not a failure to use microservices.

Microservices are not a sign that an application has matured.

Build clear boundaries, keep your architecture modular, and introduce distributed services when the complexity and requirements of the system actually justify them.

Don't choose microservices because they sound advanced. Choose them because your system has a problem that microservices solve.

Memoization: Stop Doing the Same Work Twice

Ahmed Omeiza — Wed, 16 Sep 2026 11:28:08 +0000

Imagine calling a function with the exact same input 100 times.

If that function performs an expensive calculation, why should your application calculate the same result 100 times?

It shouldn't.

That's where memoization comes in.

What Is Memoization?

Memoization is an optimization technique where you store the result of an expensive function call and reuse it when the same input appears again.

Think of it like a notebook.

The first time you solve a problem, you write down the answer. Next time you encounter the exact same problem, you look at your notes instead of solving it again.

For example:

int Square(int number)
{
    return number * number;
}

Without memoization:

Square(10) → calculate → 100
Square(10) → calculate → 100
Square(10) → calculate → 100

With memoization:

Square(10) → calculate → 100 → store

Square(10) → return stored 100
Square(10) → return stored 100

The second and third calls don't need to perform the calculation again.

How Does It Work?

Memoization usually involves a cache.

The basic flow is:

Function called
      ↓
Have we seen this input before?
      ↓
   Yes ─────→ Return cached result
      │
      No
      ↓
Calculate result
      ↓
Store result
      ↓
Return result

Here's a simple C# example:

Dictionary<int, int> cache = new();

int Square(int number)
{
    if (cache.TryGetValue(number, out var result))
        return result;

    result = number * number;
    cache[number] = result;

    return result;
}

Now, once Square(10) has been calculated, the result is stored.

Future calls can retrieve it directly.

Memoization vs Caching

These concepts are closely related, but they're not exactly the same.

Caching is the broader concept of storing data so it can be retrieved faster later.

Memoization specifically refers to caching the result of a function based on its inputs.

For example:

Caching:
Database query → store result → reuse result

Memoization:
calculate(10) → store result for input 10 → reuse result

You can think of memoization as a specific form of caching.

A Classic Example: Fibonacci

Memoization becomes much more useful when a function repeatedly calculates the same values.

Consider Fibonacci:

int Fibonacci(int n)
{
    if (n <= 1)
        return n;

    return Fibonacci(n - 1) + Fibonacci(n - 2);
}

For something like:

Fibonacci(5)

the function calculates some values multiple times.

For larger values, the number of repeated calculations grows rapidly.

With memoization:

Dictionary<int, int> cache = new();

int Fibonacci(int n)
{
    if (n <= 1)
        return n;

    if (cache.TryGetValue(n, out var result))
        return result;

    result = Fibonacci(n - 1) + Fibonacci(n - 2);

    cache[n] = result;

    return result;
}

Now, once Fibonacci(3) has been calculated, we don't calculate it from scratch every time we need it.

We simply reuse the stored result.

When Should You Use Memoization?

Memoization is useful when:

A function is expensive to execute.
The same inputs occur repeatedly.
The function is deterministic.
The result doesn't change for the same input.

For example:

Input: 5
Output: 120

If 5 will always produce 120, storing that result makes sense.

Memoization is especially common in:

Recursive algorithms
Dynamic programming
Mathematical calculations
Parsing and processing
Expensive transformations
Applications with repeated computations

When Memoization Can Be a Bad Idea

Memoization isn't free.

You're trading memory for speed.

Every cached result takes memory, and if the inputs are constantly changing, the cache may provide very little benefit.

For example:

calculate(1)
calculate(2)
calculate(3)
calculate(4)
calculate(5)
...
calculate(1,000,000)

If every input is unique, you're storing lots of results without getting many cache hits.

You also need to think about stale data if the underlying result can change.

The Key Takeaway

Memoization is a simple idea:

If you've already done the work for the same input, don't do it again.

Store the result.

Reuse it.

Save computation.

But remember the trade-off:

Memoization improves performance by spending memory.

The real skill isn't just knowing how to memoize.

It's knowing when repeated computation is expensive enough to justify caching the result.

Deadlocks: When Your Threads Are Waiting Forever

Ahmed Omeiza — Tue, 15 Sep 2026 06:42:34 +0000

Your application is running. No exception. No crash.

But two requests are stuck indefinitely.

Welcome to a deadlock.

A deadlock happens when two or more threads are waiting for resources held by each other, so none of them can continue.

What Is a Deadlock?

Imagine two developers:

Developer A has Resource 1 and needs Resource 2.
Developer B has Resource 2 and needs Resource 1.

Both are waiting.

Neither can move forward.

That's essentially what happens with threads and locks.

Thread A → holds Lock 1 → waiting for Lock 2
Thread B → holds Lock 2 → waiting for Lock 1

Result: DEADLOCK

The important part is that both threads are waiting for each other.

A Simple C# Example

Consider this:

object lockA = new();
object lockB = new();

void MethodA()
{
    lock (lockA)
    {
        Thread.Sleep(100);

        lock (lockB)
        {
            Console.WriteLine("Method A");
        }
    }
}

void MethodB()
{
    lock (lockB)
    {
        Thread.Sleep(100);

        lock (lockA)
        {
            Console.WriteLine("Method B");
        }
    }
}

If two threads execute these methods at the same time:

Thread 1:
Locks A
↓
Waits for B

Thread 2:
Locks B
↓
Waits for A

Neither thread can acquire the lock it needs.

The application can remain stuck indefinitely.

Why Do Deadlocks Happen?

Deadlocks usually involve a combination of these conditions:

1. Mutual Exclusion

A resource can only be used by one thread at a time.

Thread A → owns Resource X
Thread B → must wait

2. Hold and Wait

A thread holds one resource while waiting for another.

Thread A:
Holding X
Waiting for Y

3. No Preemption

A resource cannot simply be taken away from the thread holding it.

The thread must release it.

4. Circular Wait

Thread A waits for Thread B, while Thread B waits for Thread A.

A → waiting for B
B → waiting for A

This circular dependency is what ultimately creates the deadlock.

How Do You Prevent Deadlocks?

One of the simplest strategies is to always acquire locks in the same order.

Instead of:

// Method A
lock (lockA)
{
    lock (lockB)
}

and:

// Method B
lock (lockB)
{
    lock (lockA)
}

Make both follow the same order:

lock (lockA)
{
    lock (lockB)
    {
        // Work
    }
}

Now both threads agree:

Lock A → Lock B

There is no circular waiting.

Other Ways to Reduce the Risk

Keep Lock Scope Small

Don't hold a lock longer than necessary.

lock (resource)
{
    // Only critical work
}

Avoid performing slow operations such as network calls or database requests while holding a lock.

Avoid Unnecessary Multiple Locks

The more locks you need to coordinate, the more opportunities you create for circular dependencies.

Use Async Carefully

Async code can introduce its own synchronization problems.

Avoid blocking asynchronous operations with:

.Result

or:

.Wait()

Prefer:

await SomeOperationAsync();

This doesn't automatically eliminate every deadlock, but it avoids an important class of blocking problems.

Deadlock vs Race Condition

These problems are often confused.

A race condition happens when multiple threads access shared data and the result depends on the timing of their execution.

A deadlock happens when threads are stuck waiting for each other.

Think of it this way:

Race condition:
"Who gets there first?"

Deadlock:
"Nobody can move."

Key Takeaway

A deadlock isn't necessarily caused by a bug that crashes your application.

Sometimes the more dangerous bug is the one that makes your application wait forever.

When working with multiple locks, remember:

Acquire locks consistently, keep lock scope small, and avoid unnecessary blocking.

Good concurrency isn't just about making multiple things run at once. It's also about making sure they can actually finish.

Middleware vs Filter in ASP.NET Core: What’s the Difference?

Ahmed Omeiza — Mon, 14 Sep 2026 13:00:53 +0000

Middleware and filters can both run before or after your request logic, but they operate at different levels of the ASP.NET Core pipeline.

Understanding that difference helps you put code in the right place instead of turning your application into a collection of random checks.

What Is Middleware?

Middleware is part of the HTTP request pipeline.

It can inspect, modify, or short-circuit an HTTP request before it reaches your endpoint. It can also process the response on the way back.

A simple middleware might log every incoming request:

public async Task InvokeAsync(HttpContext context)
{
    Console.WriteLine($"Request: {context.Request.Path}");

    await _next(context);

    Console.WriteLine($"Response: {context.Response.StatusCode}");
}

Middleware is useful for concerns that apply broadly across your application.

Common examples:

Authentication
Exception handling
Logging
CORS
Request/response manipulation
Rate limiting

Think of middleware as a checkpoint for the entire HTTP pipeline.

What Is a Filter?

Filters are part of the ASP.NET Core MVC/controller pipeline.

They run at specific stages around controller actions.

For example, an authorization filter can check whether a user is allowed to execute an action before the controller action runs.

public class AdminOnlyFilter : IAuthorizationFilter
{
    public void OnAuthorization(AuthorizationFilterContext context)
    {
        if (!context.HttpContext.User.IsInRole("Admin"))
        {
            context.Result = new ForbidResult();
        }
    }
}

Filters are useful when the behavior is specifically related to MVC/controller actions.

Common filter types include:

Authorization filters
Resource filters
Action filters
Exception filters
Result filters

Think of a filter as a checkpoint specifically around controller execution.

Middleware vs Filter

Middleware	Filter
Works at the HTTP pipeline level	Works inside the MVC/controller pipeline
Can apply to almost every request	Mainly applies to MVC/controller endpoints
Runs before routing or at specific middleware positions	Runs around controller/action execution
Good for global concerns	Good for controller/action-specific concerns
Uses `HttpContext`	Has access to MVC-specific context

The biggest difference is scope.

Middleware doesn't need to care whether the request eventually reaches a controller, Razor Page, or another endpoint.

A filter is more closely connected to the MVC execution process.

A Simple Example

Imagine you want to log every request entering your API.

Middleware is a good choice:

Request
   ↓
Logging Middleware
   ↓
Authentication
   ↓
Authorization
   ↓
Controller

But suppose you want to run some logic only before a specific controller action.

A filter makes more sense:

Request
   ↓
Middleware
   ↓
Controller
   ↓
Action Filter
   ↓
Controller Action

The decision comes down to where the behavior belongs in the pipeline.

Can You Use Both?

Absolutely.

A typical ASP.NET Core application might use middleware for global concerns:

HTTP Request
     ↓
Exception Middleware
     ↓
Logging Middleware
     ↓
Authentication Middleware
     ↓
Authorization Middleware
     ↓
MVC Pipeline
     ↓
Action Filter
     ↓
Controller Action

They aren't competing technologies.

They solve problems at different levels.

The Key Takeaway

Use middleware when the concern belongs to the HTTP request pipeline. Use filters when the concern is specifically tied to MVC/controller execution.

A simple rule to remember:

Middleware is broader. Filters are more specific.

Knowing where your logic belongs makes your ASP.NET Core applications cleaner, easier to maintain, and easier to reason about.

DEV Community: Ahmed Omeiza

CORS Explained: Why Your Browser Blocks Your API

What Is CORS?

Why Does CORS Exist?

A Simple Example

CORS in ASP.NET Core

What About AllowAnyOrigin()?

What Is a Preflight Request?

CORS Is a Browser Restriction

CORS ≠ Authentication

A Common Mistake

Key Takeaway

Webhooks vs Polling: How Should Your Systems Communicate?

Polling: “Has anything happened yet?”

The problem

Webhooks: “I’ll tell you when it happens.”

Webhooks vs Polling

When should you use polling?

When should you use webhooks?

One important webhook problem

The key takeaway

Cursor Pagination vs Offset Pagination: Which One Should You Use?

Offset Pagination

The problem with large offsets

Cursor Pagination

The Key Difference

When Should You Use Offset Pagination?

When Should You Use Cursor Pagination?

One Important Detail: Your Cursor Needs an Order

So Which Should You Choose?

Key Takeaway

HTTP/1.1 vs HTTP/2 vs HTTP/3: What Actually Changed?

HTTP/1.1: Simple, But Sequential

HTTP/2: Multiple Requests Over One Connection

Binary Instead of Text

Header Compression

Server Push

HTTP/3: HTTP Over QUIC

The Big Difference: Head-of-Line Blocking

Connection Establishment

HTTP/1.1 vs HTTP/2 vs HTTP/3

What Should Developers Care About?

The Key Takeaway

OpenTelemetry in .NET: Stop Guessing What Your Application Is Doing

What is OpenTelemetry?

Why Does This Matter in .NET?

Traces: Following a Request

Metrics: Measuring Performance

Logs: Understanding Events

Setting Up OpenTelemetry in ASP.NET Core

Where Does the Data Go?

Automatic vs Manual Instrumentation

OpenTelemetry Is Not Just Logging

The Key Takeaway

Rate Limiting: The Traffic Cop Your API Needs

Why Do We Need Rate Limiting?

A Simple Example

How Does Rate Limiting Know Who to Limit?

Common Rate-Limiting Algorithms

Fixed Window

Sliding Window

Token Bucket

Rate Limiting in ASP.NET Core

Rate Limiting vs Authentication

The Key Takeaway

Process vs Thread: What’s Really Running Your Application?

What Is a Process?

What Is a Thread?

The Biggest Difference

Process vs Thread

A Practical Example

What Happens When a Thread Crashes?

When Should You Think About Processes vs Threads?

Key Takeaway

YAML vs JSON: Same Data, Different Trade-offs

JSON: Simple and Strict

YAML: Designed for Humans

YAML vs JSON

1. Readability

2. Syntax

What About `AllowAnyOrigin()`?