DEV Community: Ahmed Omeiza

Infrastructure as Code (IaC): Stop Managing Infrastructure Manually

Ahmed Omeiza — Fri, 16 Oct 2026 07:29:31 +0000

Imagine deploying an application to production, only to discover that the server configuration is different from your development environment.

The application works perfectly locally, but fails in production.

Why? Because someone forgot to configure a firewall rule, install a dependency, or update an environment variable.

This is one of the problems Infrastructure as Code (IaC) solves.

Instead of manually configuring servers, databases, networks, and cloud resources, you define your infrastructure using code.

What Is Infrastructure as Code?

Infrastructure as Code (IaC) is the practice of provisioning and managing infrastructure through machine-readable configuration files rather than manual processes.

Think of it like this:

Traditional Infrastructure Management:

Log into your cloud provider.
Create a virtual machine.
Configure networking and security rules.
Set up databases and storage.
Repeat the process for every environment.

Infrastructure as Code:

Define your infrastructure in configuration files.
Store those files in Git.
Apply the configuration using an IaC tool.
Automatically provision the required resources.

The infrastructure becomes reproducible, version-controlled, and easier to maintain.

How Does Infrastructure as Code Work?

IaC tools read configuration files describing the infrastructure you want and interact with cloud provider APIs to create or modify the required resources.

For example, using Terraform, you can define an AWS S3 bucket:

resource "aws_s3_bucket" "app_storage" {
  bucket = "my-unique-app-storage-bucket"
}

After configuring the AWS provider and your credentials, you can execute:

terraform init
terraform plan
terraform apply

What happens?

terraform init initializes the working directory and downloads providers.
terraform plan previews the proposed infrastructure changes.
terraform apply applies the approved changes.

Instead of manually creating the bucket through the AWS console, Terraform manages it using configuration files.

And when you need to modify your infrastructure, you update the code.

Declarative vs. Imperative Infrastructure

There are two common approaches to infrastructure automation.

1. Declarative Approach

You describe what the infrastructure should look like.

The tool determines how to achieve that desired state.

Example: Terraform, AWS CloudFormation.

2. Imperative Approach

You describe how to configure the infrastructure through a sequence of commands or tasks.

Example: Shell scripts and imperative automation workflows.

The key difference?

Declarative = What you want.

Imperative = How to achieve it.

Both approaches are useful, but declarative tools are particularly effective for managing the desired state of cloud infrastructure.

Why Is Infrastructure as Code Important?

1. Consistency Across Environments

Development, staging, and production environments can be provisioned using the same reusable configurations, with environment-specific parameters.

This reduces configuration drift.

2. Faster Deployment

Infrastructure that previously required multiple manual configuration steps can be provisioned through automated workflows.

3. Version Control

Infrastructure configurations can live in Git alongside application code.

You can review changes, track history, and understand how infrastructure evolves.

4. Improved Collaboration

Infrastructure changes can go through pull requests, code reviews, testing, and approval processes.

5. Scalability

Need additional servers, databases, or networking resources?

Update the configuration instead of repeating manual provisioning steps.

Popular Infrastructure as Code Tools

Several tools support infrastructure automation:

Terraform: Declarative infrastructure provisioning across multiple cloud providers.
OpenTofu: An open-source infrastructure provisioning tool built from Terraform's open-source lineage.
AWS CloudFormation: Declarative infrastructure provisioning for AWS.
Pulumi: Infrastructure provisioning using programming languages such as C#, Python, and TypeScript.
Ansible: Automation and configuration management, often used to configure systems after provisioning.

The right tool depends on your cloud provider, existing technology stack, and infrastructure requirements.

Infrastructure as Code Is Not Without Challenges

IaC does not automatically eliminate infrastructure problems.

Poorly managed configurations can still cause outages, security vulnerabilities, and unexpected costs.

A few practices make IaC safer:

Review infrastructure changes before applying them.
Protect state files and avoid committing secrets.
Use reusable modules to reduce duplication.
Restrict deployment permissions using least privilege.
Detect configuration drift and test changes before production.

Infrastructure automation is powerful, but it still requires proper engineering practices.

Key Takeaway

Infrastructure should be treated with the same discipline as application code.

It should be version-controlled, reviewed, tested, and deployed through repeatable processes.

Infrastructure as Code is not simply about automating cloud resource creation.

It's about making infrastructure consistent, reproducible, auditable, and easier to manage at scale.

If your application deployment is automated but your infrastructure is still configured manually, you've only automated half the process.

Unit Tests vs Integration Tests: What's the Difference, and Why Do You Need Both?

Ahmed Omeiza — Thu, 15 Oct 2026 09:22:14 +0000

Your code passes every unit test. Everything looks perfect.

Then you deploy, and suddenly your application starts failing.

The database connection isn't working. An API returns unexpected data. Two components that work perfectly on their own fail when communicating.

This is why passing unit tests doesn't guarantee a working application.

Let's understand the difference between Unit Tests and Integration Tests, and when to use each.

1. What Are Unit Tests?

Unit tests verify that individual pieces of code work correctly in isolation.

A unit could be a method, function, or class.

The goal is simple: Does this specific piece of code behave as expected?

For example, imagine you're building a banking application with a method that calculates transaction fees.

public decimal CalculateFee(decimal amount)
{
    return amount * 0.01m;
}

A unit test using xUnit might look like this:

[Fact]
public void CalculateFee_ShouldReturnOnePercent()
{
    var service = new TransactionService();

    var fee = service.CalculateFee(1000m);

    Assert.Equal(10m, fee);
}

This test checks one thing: whether the calculation produces the expected result.

It doesn't need a database, external API, or running server.

Advantages of Unit Tests:

Fast to execute
Easy to debug
Help catch logic errors early
Provide quick feedback during development
Encourage modular, maintainable code

Limitation: Unit tests cannot guarantee that independently tested components will work correctly together.

2. What Are Integration Tests?

Integration tests verify that multiple components work correctly when connected.

Instead of testing a single method, you're testing how different parts of your application interact.

For example, consider a banking API that processes transfers.

A transfer might involve:

Receiving an HTTP request.
Validating the transaction.
Checking the account balance.
Updating the database.
Returning a response.

Each component might pass its unit tests, but what happens when they work together?

That's what integration tests help verify.

Here's a simplified ASP.NET Core integration test using xUnit and WebApplicationFactory:

public class TransferTests :
    IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient _client;

    public TransferTests(
        WebApplicationFactory<Program> factory)
    {
        _client = factory.CreateClient();
    }

    [Fact]
    public async Task Transfer_ShouldRejectInvalidAmount()
    {
        var response = await _client.PostAsJsonAsync(
            "/api/transfers",
            new { Amount = -100 }
        );

        Assert.Equal(
            HttpStatusCode.BadRequest,
            response.StatusCode
        );
    }
}

This test sends an HTTP request through the application's test host and checks whether the API rejects an invalid amount.

It verifies more than a single method, including HTTP routing, model binding, and relevant request-processing components.

A broader integration test could also verify database persistence using an isolated test database.

Advantages of Integration Tests:

Detect communication problems between components
Verify API and database interactions
Catch configuration and dependency-injection issues
Provide confidence that connected components behave correctly

Limitations:

Generally slower than unit tests
Require more setup
Failures can be harder to diagnose
May depend on infrastructure such as databases or message brokers

3. Unit Tests vs Integration Tests: Key Differences

Unit Tests

Focus: Individual methods, functions, or classes
Scope: Small and isolated
Speed: Usually very fast
Dependencies: Typically replaced with mocks or fakes
Debugging: Easier to pinpoint failures
Example: Checking whether a transaction fee is calculated correctly

Integration Tests

Focus: Interactions between components
Scope: Multiple connected components
Speed: Generally slower
Dependencies: Often use real components or test infrastructure
Debugging: May require investigating several layers
Example: Verifying that a transfer API correctly updates account balances in a database

4. When Should You Use Each?

Use Unit Tests when testing business rules, calculations, validation logic, or methods that can be isolated from external dependencies.

Use Integration Tests when testing database operations, API endpoints, service communication, authentication pipelines, or messaging infrastructure.

For example, in a financial application:

Unit test that a transfer cannot exceed the available balance.
Integration test that a successful transfer correctly updates both accounts in the database.
Unit test that a transaction fee is calculated correctly.
Integration test that the API returns the correct response when a transfer is rejected.

Neither type of test replaces the other.

5. Why You Need Both

Imagine building an application using only unit tests.

Your business logic might be perfectly tested, but you could still have broken database queries, incorrect API configurations, or failed service integrations.

Now imagine relying only on integration tests.

You might catch those problems, but your tests could become slower and make simple logic bugs harder to identify.

A practical testing strategy combines both:

Unit Tests → Integration Tests → End-to-End Tests

Unit tests provide fast feedback on individual components.

Integration tests verify that components work together.

End-to-end tests validate complete user workflows across the system.

The goal isn't to write the largest number of tests. It's to build confidence that your application behaves correctly.

Key Takeaway

Unit tests verify that individual components work correctly. Integration tests verify that those components work correctly together.

Good software needs both.

Because working code is important, but working systems are what users actually depend on.

Profiling a Slow Application: Stop Guessing, Start Measuring

Ahmed Omeiza — Wed, 14 Oct 2026 08:25:03 +0000

Your application is slow. Users are complaining. API requests are taking too long, and pages are struggling to load.

Your first instinct might be to optimize the database, add caching, or rewrite some code.

But what if none of those is the actual problem?

The fastest way to fix a slow application is to stop guessing and start profiling.

What Is Application Profiling?

Application profiling is the process of measuring how an application uses resources such as CPU, memory, and execution time.

Instead of assuming where the performance problem exists, profiling helps you identify the actual bottleneck.

For example, imagine an API endpoint takes 3 seconds to respond.

A profiler might reveal:

Database queries: 2,200ms
Business logic: 300ms
External API calls: 400ms
Other processing: 100ms

Now you know where to focus.

Optimizing business logic won't make much difference when database queries consume most of the response time.

How to Profile a Slow Application

1. Reproduce the Performance Problem

Before optimizing anything, reproduce the slowness under measurable conditions.

Ask yourself:

Which endpoint or operation is slow?
Does it happen under heavy traffic?
Is the problem consistent or occasional?
How long does the operation actually take?

Use tools like Chrome DevTools, Postman, or k6 to measure response times and reproduce performance issues.

You cannot reliably improve what you haven't measured.

2. Identify the Bottleneck

Once you can reproduce the problem, investigate where execution time is being spent.

Common bottlenecks include:

CPU bottlenecks: Expensive calculations, inefficient algorithms, or unnecessary processing.

Memory bottlenecks: Excessive allocations, memory leaks, or frequent garbage collection.

Database bottlenecks: Slow queries, missing indexes, or repeated database calls.

Network bottlenecks: Slow external APIs, excessive requests, or large payloads.

Useful profiling tools include:

Chrome DevTools: Frontend performance and JavaScript execution.
Python cProfile: Function-level execution profiling.
Node.js Inspector: CPU profiling and memory analysis.
Pyroscope: Continuous application profiling.
OpenTelemetry: Distributed tracing to identify latency across services.

Tracing and profiling complement each other: tracing shows where a request spends time across components, while profiling reveals what the code is doing within a process.

3. Optimize the Actual Problem

Imagine your application retrieves 100 products from a database.

For each product, it executes another query to fetch its category.

products = get_products()

for product in products:
    product.category = get_category(product.category_id)

This creates the classic N+1 query problem.

Instead of executing one query, your application executes 101 queries.

A better approach is to fetch the required data in fewer queries:

products = get_products_with_categories()

Depending on your database and ORM, this might use a JOIN or eager loading.

The result?

Fewer database round trips and potentially much faster response times.

The important point is that profiling helped you identify the problem before making changes.

4. Measure Again

Optimization isn't complete when your code looks cleaner.

It's complete when measurements show meaningful improvement.

Suppose your endpoint originally took 3 seconds.

After optimizing the database queries:

Before: 3,000ms
After: 450ms
Improvement: 85% reduction in response time

That's a measurable performance improvement.

However, don't stop at average response time. Check p95 and p99 latency, CPU usage, memory consumption, and error rates under comparable workloads.

An optimization that improves one metric but introduces instability isn't necessarily a win.

The Common Mistake Developers Make

Many developers optimize code that looks inefficient without confirming whether it affects application performance.

They rewrite loops, introduce caching, or change frameworks.

Sometimes these changes help.

Other times, they add complexity without solving anything.

Profiling changes the question from "What code looks slow?" to "What is actually consuming time and resources?"

Key Takeaway

Performance optimization should follow a simple cycle:

Measure → Profile → Identify → Optimize → Measure Again

Don't optimize based on assumptions.

Find the bottleneck, fix it, and verify the improvement.

The best performance optimization isn't always the most complicated one. It's the one that fixes the actual problem.

Chaos Engineering: Why Breaking Your System Makes It More Reliable

Ahmed Omeiza — Wed, 14 Oct 2026 08:19:02 +0000

Your application works perfectly. Until something fails in production.

A database becomes unavailable. A network request times out. A server crashes unexpectedly.

Suddenly, an application that passed every test starts falling apart.

The problem isn't necessarily that your code is broken. It's that your system was never tested under failure conditions.

That's where Chaos Engineering comes in.

What Is Chaos Engineering?

Chaos Engineering is the practice of deliberately introducing controlled failures into a system to understand how it behaves under unexpected conditions.

Instead of waiting for something to break in production, you simulate failures to discover weaknesses before they cause major outages.

The idea is simple:

Don't just test whether your system works. Test whether it can survive when things go wrong.

How Does Chaos Engineering Work?

Imagine you're building an e-commerce application with three services:

Order Service: Handles customer orders.
Payment Service: Processes transactions.
Notification Service: Sends order confirmations.

Under normal conditions, everything works perfectly.

But what happens if the Payment Service suddenly becomes unavailable?

Does the Order Service crash?

Does the customer get charged twice when the request is retried?

Does the application return a meaningful error?

These are the questions Chaos Engineering helps answer.

A typical experiment follows five steps.

1. Define normal behavior

Establish how the system should behave.

For example, 99% of payment requests should complete successfully within two seconds.

2. Form a hypothesis

Predict what should happen during a failure.

For example, if the Payment Service becomes unavailable, the Order Service should return a controlled error without crashing.

3. Introduce a controlled failure

Simulate conditions such as:

Server shutdowns
Network latency
Database connection failures
CPU or memory pressure
Service unavailability

4. Observe the system

Monitor error rates, response times, logs, and service health to understand how the application responds.

5. Analyze and improve

If the system behaves unexpectedly, identify the weakness, implement a fix, and repeat the experiment.

A Practical Example: Simulating Network Failure

Let's say your application depends on an external payment API.

Under normal conditions, the API responds in 200 milliseconds.

But what happens when the response takes 10 seconds?

Without proper timeout handling, requests may pile up and exhaust available resources.

Chaos Engineering helps you discover this problem before real customers experience it.

For example, using Toxiproxy, you can simulate network latency between your application and a dependency:

toxiproxy-cli toxic add payment_api \
  --type latency \
  --attribute latency=5000

Assuming payment_api is a configured Toxiproxy proxy, this introduces 5 seconds of latency.

Now you can observe whether your application:

Times out appropriately.
Returns a meaningful error.
Prevents uncontrolled retries.
Recovers when the dependency becomes healthy.

The goal isn't simply to make the application fail.

It's to understand whether failure is handled gracefully.

Chaos Engineering vs Traditional Testing

Traditional testing primarily verifies whether an application behaves correctly under expected conditions.

Chaos Engineering explores how the system behaves when infrastructure or dependencies fail.

For example:

Traditional testing:
Does the checkout endpoint successfully process an order?

Chaos Engineering:
What happens to checkout when the database becomes temporarily unavailable?

Both approaches are important.

Traditional testing helps establish correctness. Chaos Engineering helps validate resilience.

Popular Chaos Engineering Tools

Several tools can help automate failure experiments.

Chaos Monkey: Terminates compute instances to test fault tolerance.
LitmusChaos: Provides chaos experiments for Kubernetes environments.
Chaos Mesh: Simulates network, infrastructure, and resource failures in Kubernetes.
Toxiproxy: Simulates network issues between applications and dependencies.

The right tool depends on your architecture and the failures you want to investigate.

Should You Run Chaos Experiments in Production?

Chaos Engineering can be performed in production, but it should never mean introducing uncontrolled failures.

Start in a staging environment where possible.

Define a hypothesis, monitor the relevant metrics, limit the experiment's impact, and establish clear conditions for stopping it.

Once you understand your system's behavior and have appropriate safeguards, you can consider carefully scoped production experiments.

The objective is to build confidence, not create unnecessary outages.

Key Takeaway

A reliable system isn't one that never experiences failure.

It's one that can handle failure without causing unnecessary disruption.

Chaos Engineering shifts your mindset from asking:

"Will this system fail?"

To asking:

"When something fails, will the system recover gracefully?"

Because in distributed systems, failures aren't exceptions.

They're part of normal operation.

Don't wait for production to expose your system's weaknesses. Discover them through controlled experiments.

CI vs CD: Passing Tests Is Only Part of Shipping Software

Ahmed Omeiza — Mon, 12 Oct 2026 07:27:18 +0000

Your code builds. The tests pass. But releasing it still involves copying files, changing settings, and hoping you remembered every step.

That gap is what CI and CD help address.

They work together, but they handle different parts of getting code into users’ hands.

CI: Integrate Changes and Catch Problems Early

Continuous Integration (CI) means developers frequently merge small changes into a shared codebase, with automated checks validating those changes.

A typical CI pipeline:

Builds the application.
Runs automated tests.
Checks code quality.

Imagine two developers working on an ASP.NET application. One changes an API response; the other updates code that depends on it.

Their changes may work separately but fail when combined. CI helps catch that conflict early, while the changes are still small enough to investigate easily.

CI gives feedback about whether changes work together. Its confidence depends on the quality of the checks—you can still ship bugs with a green pipeline.

CD: Make Releases Repeatable

CD can mean Continuous Delivery or Continuous Deployment. This distinction matters.

Continuous Delivery

Changes that pass the pipeline are kept ready for release. The pipeline automates the steps needed to prepare and validate a release, but production deployment still requires a deliberate approval or action.

For example, a release is deployed to staging automatically. After reviewing it, someone approves deployment to production.

Continuous Deployment

Every change that passes the required checks is automatically deployed to production.

There is no routine manual approval between successful validation and deployment.

Practice	Main purpose	Production deployment
Continuous Integration	Validate frequently integrated changes	Not required
Continuous Delivery	Keep validated changes ready for release	Requires a deliberate decision
Continuous Deployment	Release validated changes automatically	Happens automatically

A Practical Example

Suppose you add pagination to an ASP.NET API.

Your pipeline builds the application, runs tests, packages it, and deploys it to staging.

The build and integration checks support CI.

If the validated release waits for production approval, you have Continuous Delivery.

If it automatically goes to production after passing all required checks, you have Continuous Deployment.

The difference is the release decision, not whether you use GitHub Actions, Jenkins, or another tool.

Which Approach Should You Use?

Start with reliable CI checks and a repeatable deployment process.

Choose Continuous Delivery when releases need deliberate approval, coordination, or scheduled timing.

Choose Continuous Deployment when your testing, monitoring, and recovery processes support automatically releasing small changes.

Automation increases release speed, but weak checks can also let mistakes reach production faster.

Key Takeaway

CI validates integrated changes. Continuous Delivery keeps them ready to release. Continuous Deployment releases them automatically.

Build confidence in your checks before removing the final approval step.

Principle of Least Privilege: Does Your App Really Need Admin Access?

Ahmed Omeiza — Sun, 11 Oct 2026 08:53:29 +0000

Your reporting service only reads sales data. So why does its database account also have permission to delete customers?

Extra permissions are easy to grant during development—and easy to forget afterward. The principle of least privilege helps prevent that convenience from becoming a security problem.

What does least privilege mean?

Give every user, application, and service only the permissions it needs to perform its job.

A service that reads reports needs access to the relevant data. It does not automatically need permission to update records, manage accounts, or change database tables. This matches NIST’s definition of granting only the minimum resources and authorizations required for a task.

The question is simple: What does this identity actually need to do?

A practical example: a reporting service

Imagine an e-commerce application with a service that generates daily sales reports.

Its database access could look like this:

Operation	Required?
Read approved sales data	Yes
Update order statuses	No
Delete customers	No
Create or drop tables	No

Give the service a dedicated database account with access to the required tables, columns, or reporting views.

If someone steals its credentials, those credentials should not authorize destructive operations. However, the attacker could still read the data the account can access. Restricting which data it can read matters too.

Least privilege limits the damage a compromised identity can cause. It does not make compromise harmless.

Apply it to users and resources

Permissions also need boundaries inside your application.

A customer may be allowed to view orders, but only their own orders. Checking that they are logged in is insufficient; the API must check whether they can access the specific order requested.

OWASP recommends denying access by default and validating permissions on every request. Hiding a button in the frontend does not enforce that rule—the backend must reject unauthorized actions.

Avoid “give it admin so it works”

When an operation fails, granting administrator access can make the error disappear without explaining which permission was missing.

Instead, identify the operation, grant the specific permission it requires, and verify that unrelated operations remain blocked.

Use separate identities for separate responsibilities. A deployment process that changes the database schema has different needs from the application serving normal requests.

There is a tradeoff: narrower permissions require more planning and maintenance. Review them as responsibilities change, so old access does not accumulate.

Key takeaway

Treat permissions as part of your application’s design. Give each identity the access its current responsibilities require, and verify that everything outside those boundaries is denied.

JSON Web Tokens: What Your API Should Actually Trust

Ahmed Omeiza — Sat, 10 Oct 2026 10:10:27 +0000

A user logs in, receives a token, and sends it with every request.

Simple enough. But decoding that token doesn’t prove it’s trustworthy.

That distinction is central to understanding JSON Web Tokens.

What is a JWT?

A JSON Web Token, or JWT, is a compact format for carrying claims between systems. Claims are statements such as who the user is, who issued the token, and when it expires.

JWTs can be signed, encrypted, or both. The signed version commonly used in APIs has three parts:

header.payload.signature

Header: Identifies the signing algorithm and token type.
Payload: Contains the claims.
Signature: Lets the recipient verify integrity using the appropriate key.

The header and payload are Base64url-encoded. Encoding does not hide their contents. A signed JWT’s payload is readable by anyone holding it.

How does it work in an API?

Consider an order management application:

The user submits their login credentials.
The authentication service verifies them and issues a signed JWT.
The client sends the token with subsequent requests.
The API validates the token before applying its access rules.

A typical request includes:

Authorization: Bearer <token>

The token might identify the user as user-42. The API can then use that identity when checking whether they may view a particular order.

Decoding is not validation

Decoding a JWT only reveals its contents. Anyone can construct a payload claiming to be an administrator.

Before trusting a token, the API must verify its cryptographic protection, restrict accepted algorithms, and check relevant claims—including the expected issuer, intended audience, and expiration.

Use a maintained validation library with explicit configuration. Don’t let an incoming token decide which algorithms your API trusts.

A valid token still needs permission checks

Imagine a valid token belongs to user-42, but the requested order belongs to user-99.

The token establishes an identity. Your application still needs to check ownership or other authorization rules.

“This token is valid” does not mean “this request is allowed.”

What about logout?

Deleting the token from the client stops that client from sending it. It does not invalidate a copy held elsewhere.

If an API relies only on token validation, a copied token can remain usable until expiration. Immediate revocation requires an additional mechanism, such as a server-side revocation check.

This is a practical tradeoff to consider when designing your authentication flow.

Key takeaway

JWTs carry claims; validation establishes whether to trust them; authorization determines what the request may do.

Keep those responsibilities clear, and your authentication flow becomes easier to understand and secure.

Pub/Sub Messaging: Let One Event Trigger Many Actions

Ahmed Omeiza — Fri, 09 Oct 2026 07:04:41 +0000

An order is placed. You need to send a confirmation email, update inventory, and notify the warehouse.

You could make the order service call every system directly. But each new integration adds another dependency—and another way for order processing to fail.

Pub/Sub offers a different approach: publish what happened and let interested systems react.

What Is Pub/Sub?

Pub/Sub stands for publish/subscribe. It is a messaging pattern with three main parts:

Publisher: Produces a message.
Topic: A named channel through which a broker routes messages.
Subscriber: Receives messages through a subscription to that topic.

The publisher does not need to know which systems consume its messages.

For example, an order service publishes this message to an orders topic:

{
  "eventId": "evt_123",
  "type": "order.created",
  "orderId": "ord_456",
  "customerId": "cus_789"
}

The email, inventory, and warehouse services each have their own subscription. Each can react to the same event independently.

Why This Helps

Add features without changing the publisher

Suppose you introduce an analytics service.

With direct calls, you may need to update the order service to call it. With Pub/Sub, you can add a subscription that receives relevant order events.

The publisher still needs to maintain a stable message contract, but it does not need to manage every consumer.

Handle work independently

An email service can process messages at a different pace from the inventory service.

With durable subscriptions and suitable retention settings, a temporarily unavailable subscriber can catch up later. That behavior depends on the messaging system and its configuration.

Keep slow work out of the request

The order service can publish an event without waiting for every downstream action to finish.

That makes processing asynchronous: an accepted order does not necessarily mean its confirmation email has already been sent.

Pub/Sub vs a Work Queue

The key difference is who should receive the message.

A work queue typically distributes each message to one worker in a group. Pub/Sub routes a message to each interested subscription.

For an order.created event:

Email and inventory need separate subscriptions because both must react.
Multiple email workers can share one subscription to divide the email workload.

Pub/Sub enables fan-out across subscriptions while allowing workers within a subscription to share the work.

The Catch: Delivery Needs Care

Pub/Sub reduces direct dependencies, but it introduces delivery concerns.

Duplicate messages: Many systems offer at-least-once delivery. A subscriber should safely handle the same event more than once—for example, by recording processed event IDs.

Failed processing: Use controlled retries and a dead-letter destination for messages that repeatedly fail.

Ordering: Do not assume global message order. Check the broker’s guarantees and configure ordering where your workflow requires it.

Consistency: Saving an order and publishing its event are separate operations. An outbox pattern can help prevent an order from being saved without its event eventually being published.

Key Takeaway

Pub/Sub lets one event reach multiple independent consumers without making the publisher coordinate them all.

Use it when several systems need to react to the same event. Design for duplicates, failures, and delayed processing from the start.

BFS vs DFS: Explore Nearby or Go Deeper?

Ahmed Omeiza — Thu, 08 Oct 2026 09:21:19 +0000

Imagine searching for a file in a folder full of subfolders.

You could check every folder at the current level before going deeper. Or you could follow one folder path all the way down, then return to explore the others.

That is the core difference between Breadth-First Search (BFS) and Depth-First Search (DFS).

Both traverse trees and graphs. What changes is the order they explore—and the problems they solve best.

Breadth-First Search: Explore Level by Level

BFS visits the starting node, then its immediate neighbors, then their neighbors.

It typically uses a queue: the first node added is the first node processed.

Consider this tree:

A has children B and C.
B has children D and E.
C has children F and G.

Starting at A and visiting children from left to right, BFS produces:

A → B → C → D → E → F → G

It finishes one level before moving to the next.

When is BFS useful?

BFS is useful when you need the shortest path by number of edges in an unweighted graph.

For example, if each connection between two people counts as one step, BFS can find the fewest connections between you and another person.

This works because BFS explores all nodes one step away before exploring nodes two steps away.

If edges have different costs, ordinary BFS does not guarantee the cheapest path.

Depth-First Search: Follow One Branch

DFS follows a branch as far as possible, then backtracks to explore another branch.

It typically uses a stack, either explicitly or through recursive function calls.

Using the same tree and visiting children from left to right, DFS produces:

A → B → D → E → C → F → G

It explores B’s entire branch before moving to C.

When is DFS useful?

DFS is useful for problems that involve exploring possibilities or relationships deeply, such as:

Detecting cycles.
Finding connected components.
Topological sorting in a directed acyclic graph.
Backtracking through puzzles and possible solutions.

DFS can find a path between nodes, but the first path it finds may not be the shortest.

BFS vs DFS at a Glance

Feature	BFS	DFS
Exploration order	Level by level	Branch by branch
Main structure	Queue	Stack or recursion
Shortest path in an unweighted graph	Guaranteed	Not guaranteed
Typical use	Fewest-step paths	Deep exploration and backtracking

For a full traversal using an adjacency list, both take O(V + E) time, where V is the number of vertices and E is the number of edges.

Memory depends on the graph’s shape. BFS can hold a large frontier in a wide graph. Recursive DFS can build a large call stack in a deep graph. Both can require O(V) auxiliary space.

One Important Detail: Track Visited Nodes

Graphs can contain cycles.

Without tracking visited nodes, your traversal may keep returning to the same nodes indefinitely.

For BFS, mark a node as visited when you enqueue it. For DFS, mark it when you first enter it.

Key Takeaway

Use BFS when you need the fewest steps in an unweighted graph. Use DFS when you need to explore branches, dependencies, or possible solutions deeply.

The right choice comes from the problem you need to solve.

Authentication vs Authorization: Who Are You, and What Are You Allowed to Do?

Ahmed Omeiza — Wed, 07 Oct 2026 08:56:08 +0000

Authentication answers “Who are you?” Authorization answers “What are you allowed to do?”

These two concepts are often mentioned together, but they solve completely different problems.

Understanding the difference is essential when building APIs, web applications, and secure systems.

Authentication: Who Are You?

Authentication is the process of verifying a user's identity.

When you log into an application with an email and password, the system checks whether those credentials belong to you.

For example:

Email: omeiza@example.com
Password: ********

If the credentials are valid, the application knows:

“This user is Omeiza.”

Other common authentication methods include:

Passwords
JWT tokens
Session cookies
OAuth
Multi-factor authentication
Biometric authentication

Authentication happens before the system can make meaningful authorization decisions.

Authorization: What Can You Do?

Once the system knows who you are, it needs to determine what you're allowed to access.

That's authorization.

Imagine you're logged into an admin dashboard.

The system knows you're Omeiza, but that doesn't automatically mean you're allowed to:

Delete users
Access financial reports
Change system settings
Promote another user to admin

Authorization determines whether you have permission to perform those actions.

For example:

User: Omeiza
Role: Admin

Action: Delete User
Result: Allowed

But:

User: John
Role: Customer

Action: Delete User
Result: Forbidden

The Difference in One Example

Think about entering an office building.

Authentication:

The security guard checks your ID and confirms:

“Yes, this is Omeiza.”

Authorization:

The guard then checks your access level:

“Omeiza can enter the office, but not the server room.”

Authentication establishes identity.

Authorization determines permissions.

How They Work Together

A typical API request might look like this:

Client
  ↓
Login
  ↓
Authentication
  ↓
JWT Token
  ↓
API Request
  ↓
Authorization
  ↓
Access Granted / Denied

For example, a user logs in and receives a JWT:

Authorization: Bearer <token>

The API validates the token to authenticate the user.

Then it checks the user's role or permissions:

Is the user authenticated?
        ↓
       Yes
        ↓
Does the user have permission?
        ↓
       Yes
        ↓
   Execute request

If the user isn't authenticated, the API typically returns:

401 Unauthorized

If the user is authenticated but doesn't have permission, the API typically returns:

403 Forbidden

This distinction is important.

401: “I don't know who you are.”

403: “I know who you are, but you're not allowed to do this.”

A Common Mistake

A common security mistake is assuming that authentication is enough.

For example:

[Authorize]
public IActionResult DeleteUser(int id)
{
    // Delete user
}

This may ensure that the user is logged in, but it doesn't necessarily mean every authenticated user should be able to delete users.

You might instead require a specific role or permission:

[Authorize(Roles = "Admin")]
public IActionResult DeleteUser(int id)
{
    // Delete user
}

Now authentication answers:

“Is this user logged in?”

Authorization answers:

“Is this user an admin?”

The Key Takeaway

Authentication identifies the user. Authorization controls what that user can do.

A secure application needs both.

Think of it this way:

Authentication = Who are you?

Authorization = What are you allowed to do?

Once you understand that distinction, many security concepts in APIs and web applications become much easier to reason about.

Partitioning vs Sharding: What’s the Difference?

Ahmed Omeiza — Tue, 06 Oct 2026 10:13:44 +0000

Your database is getting bigger. Queries are getting slower. Your server is starting to struggle.

You hear two solutions: partitioning and sharding.

They sound similar because both split data into smaller pieces. But they solve the problem at different levels.

Let’s break it down.

What Is Database Partitioning?

Partitioning splits a large table into smaller logical pieces called partitions, while keeping them within the same database system.

For example, imagine an Orders table with 100 million records.

Instead of keeping everything in one huge table, you could partition it by year:

Orders
├── 2024
├── 2025
├── 2026
└── 2027

A query such as:

SELECT *
FROM Orders
WHERE OrderDate >= '2026-01-01';

can potentially access only the relevant partition instead of scanning the entire table.

Common Partitioning Strategies

Range partitioning

Split data based on ranges.

2024 orders → Partition 1
2025 orders → Partition 2
2026 orders → Partition 3

List partitioning

Split data based on specific values.

Nigeria → Partition 1
Ghana   → Partition 2
Kenya   → Partition 3

Hash partitioning

Use a hash function to distribute rows across partitions.

Hash(CustomerId) → Partition 1, 2, 3...

The important thing is that the partitions are still managed as part of the same database environment.

What Is Sharding?

Sharding takes the idea further.

Instead of splitting a table inside one database, you distribute the data across multiple independent database instances or servers.

For example:

Shard 1 → Customers 1–1,000,000
Shard 2 → Customers 1,000,001–2,000,000
Shard 3 → Customers 2,000,001–3,000,000

Each shard can have its own:

Database
CPU
Memory
Storage
Connections

This allows the workload to be distributed across multiple machines.

For example, a large application might route customers based on CustomerId:

CustomerId → Shard
     101   → Shard 1
  1500000  → Shard 2
  2500000  → Shard 3

Partitioning vs Sharding

The easiest way to remember the difference:

	Partitioning	Sharding
Splits data	Inside a database	Across databases
Infrastructure	Usually one database system	Multiple database instances/servers
Main goal	Manage large tables efficiently	Scale database workloads horizontally
Complexity	Lower	Higher
Application involvement	Usually minimal	Often significant

Think of it this way:

Partitioning:

"Let's organize this huge table into smaller pieces."

Sharding:

"This database is too much for one machine, so let's distribute the data across multiple machines."

Can You Use Both?

Absolutely.

A large-scale system might use sharding and partitioning together.

For example:

                 Database Cluster
                       │
          ┌────────────┼────────────┐
          │            │            │
       Shard 1      Shard 2      Shard 3
          │            │            │
       ┌──┴──┐       ┌──┴──┐       ┌──┴──┐
       2025  2026    2025  2026    2025  2026

Each shard could contain partitioned tables.

This is useful when an application has both very large datasets and high traffic.

Which One Should You Use?

Don't jump straight to sharding because it sounds more scalable.

Partitioning is often the simpler solution when:

Your tables are becoming very large.
Queries frequently filter by a predictable column such as date.
You want easier data management.
A single database server can still handle your workload.

Sharding becomes more attractive when:

A single database server is reaching its limits.
You need to scale horizontally.
Your dataset is extremely large.
Database traffic needs to be distributed across multiple machines.

Sharding also introduces significant complexity around routing, joins, transactions, backups, and operational management.

The Key Takeaway

Partitioning divides data within a database. Sharding distributes data across databases.

Partitioning is primarily about organizing and managing large datasets efficiently.

Sharding is primarily about scaling database capacity across multiple machines.

So before reaching for sharding, ask a simpler question:

"Is my database too big, or is one database server no longer enough?"

That distinction can determine which solution you actually need.

CAP Theorem: The Trade-Off Behind Distributed Systems

Ahmed Omeiza — Mon, 05 Oct 2026 07:12:10 +0000

What if your database has multiple servers, and they suddenly can’t communicate with each other?

Should the system keep accepting requests, even if some servers might have outdated data?

Or should it reject requests until everything is synchronized?

This is where the CAP Theorem comes in.

What Is CAP Theorem?

CAP states that a distributed system can guarantee at most two out of three properties:

Consistency
Availability
Partition Tolerance

Let's break them down.

1. Consistency

Every read gets the most recent write.

Imagine you update your bank balance from ₦50,000 to ₦40,000.

With strong consistency, every server should immediately return:

₦40,000

No server should return the old ₦50,000.

2. Availability

Every request receives a response, even when some parts of the system are failing.

If one server goes down, another server should still be able to respond.

The system prioritizes staying operational.

3. Partition Tolerance

The system continues working even when communication between servers is interrupted.

For example:

Server A  X  Server B
          ↑
   Network failure

Server A and Server B are still running, but they can't communicate.

That's a network partition.

The Important Part: You Can't Ignore Partitions

Here's the part that is often misunderstood.

CAP doesn't simply mean:

"Pick any two of the three."

In a distributed system, network partitions can happen.

When a partition occurs, you have to choose between:

Consistency (C)
or
Availability (A)

You still need Partition Tolerance (P).

So during a network failure:

C + P → Prefer correct, consistent data
A + P → Prefer staying available

A Simple Example

Imagine an e-commerce system with two servers:

        Database
       /        \
   Server A    Server B

A network failure occurs:

   Server A  X  Server B

A customer buys the last available product through Server A.

Server B doesn't know about the purchase because the servers can't communicate.

Now another customer requests the same product through Server B.

What should happen?

Choose Consistency

Server B could reject the request because it cannot guarantee that its data is current.

You sacrifice availability to protect consistency.

Choose Availability

Server B could continue accepting requests using its local data.

The system remains available, but users might temporarily see inconsistent information.

You sacrifice consistency to protect availability.

CAP Isn't About "Fast vs Slow"

CAP is specifically about distributed systems experiencing network partitions.

It's not a general rule that says:

"You can only have two of the three properties."

In normal operation, a system can provide both strong consistency and high availability.

The trade-off becomes important when a network partition occurs.

Why CAP Matters

CAP helps engineers understand why distributed databases make different design decisions.

Some systems prioritize:

Consistency

Useful when incorrect or stale data is unacceptable.

Others prioritize:

Availability

Useful when keeping the system operational is more important than immediately having perfectly synchronized data.

Neither choice is automatically better.

It depends on the application.

Key Takeaway

CAP Theorem is really about what happens when distributed systems can't communicate.

When a network partition occurs, you generally have to choose:

Consistency or Availability.

Understanding that trade-off helps you make better decisions when designing distributed systems, databases, and highly available applications.