DEV Community: Nsikan Patrick Adaowo

N+1 Queries: Your ORM Is Lying to You and Your Database Is Paying the Bill

Nsikan Patrick Adaowo — Sat, 31 Oct 2026 14:02:39 +0000

Your ORM is supposed to make database access easier, so why is your application making hundreds of database queries to return a single response?

You define your models, establish your relationships, and let the ORM handle the details. No complicated SQL. No messy joins. Just clean, readable application code.

Except there’s a problem.

That innocent-looking loop might be querying the database once for every record it retrieves. Your code stays simple, but your database pays for every additional round trip.

And adding an index might make those queries faster without fixing the underlying problem.

The issue isn’t always how efficiently you’re querying your database. Sometimes, it’s how many times you’re querying it in the first place.

This is the N+1 query problem. And it’s particularly frustrating because the code that introduces it can look perfectly reasonable.

An ORM promises to make database interactions easier to work with. It gives you models, relationships, and convenient methods for retrieving data. But convenient database access is not the same thing as efficient database access.

Your application code might look simple while the database handles a workload that was never necessary.

What Exactly Is an N+1 Query Problem?

Imagine you’re building a SaaS application with users and their projects.
You need an endpoint that returns a list of users alongside the projects each user owns.

The data model is straightforward:
A User can own many Project records.

Each Project belongs to one User.

In a relational database, this is a familiar one-to-many relationship.

The naive implementation might look like this:

Nothing about this code looks particularly alarming.

You retrieve the users, loop through them, and fetch each user’s projects. The code is readable, the relationship is clear, and the response has the shape you need.

But look at what happens at the database level.

The first query retrieves the users:

SELECT * FROM "User";

Then, for every user returned, the application executes another query:

SELECT * FROM "Project" WHERE "userId" = $1;

If the first query returns 50 users, the database receives:

1 query to retrieve the users.
50 additional queries to retrieve their projects.

That’s 51 queries to construct one response.

If the endpoint returns 500 users, it can execute 501 queries.

This is why the problem is called N+1: one initial query, followed by N additional queries.

The exact number depends on the data and the code path, but the underlying issue remains the same: the number of database queries grows with the number of records returned by the initial query.
And that growth can happen without any obvious change to the service’s complexity or readability.

Why N+1 Queries Are More Expensive Than They Look

A common mistake is to assume that an individual query is cheap, so executing many of them must also be cheap.
That assumption ignores the work surrounding each query.

A database query isn’t just the time PostgreSQL spends executing SQL. The application and database must also coordinate the operation.

Depending on the driver, connection pool, network, and execution path, each query may involve:

Sending a request from the application to the database.
Parsing, planning, or executing the statement as applicable.
Reading or modifying the relevant data.
Returning the result to the application.
Converting the result into application-level objects.

Some of these costs can be reduced through prepared statements, connection reuse, or other optimizations. But repeating a query still creates work.
Consider a simplified example.

Suppose each additional query takes an average of 5 milliseconds from the application’s perspective, including the relevant round-trip and processing overhead.

With 100 users, the endpoint executes 101 queries.

If those additional queries run sequentially, the repeated database operations alone could account for roughly 500 milliseconds, before adding the initial query, serialization, and other application work.

That number is illustrative, not a performance benchmark. Actual latency depends on the environment and workload.

The important point is that a query taking only a few milliseconds can become a serious problem when repeated hundreds of times.

And sequential execution isn’t the only concern.

The database is doing unnecessary work

Every additional query consumes some combination of database CPU, connection time, query execution resources, memory, and I/O.

Even when an index makes each lookup efficient, the database still has to process every request.
An index can make a query faster. It cannot eliminate the need to execute that query 100 times.

Your connection pool becomes a bottleneck

Database connections are finite resources.

When an application generates large numbers of queries, those queries must compete for available connections and database capacity.

This becomes particularly problematic when multiple requests are doing the same thing simultaneously.

One endpoint might execute 101 queries. Fifty concurrent requests could generate thousands of database operations in a short period.

The result can be increased connection wait time, growing latency, and reduced throughput.

Your tail latency gets worse

Users don’t experience your endpoint as a collection of individually fast queries. They experience the total time required to receive a response.

A route that performs unnecessary database operations can have acceptable average latency under light traffic and terrible p95 or p99 latency under load.

This is why N+1 problems often become obvious only after an application starts receiving meaningful traffic.
The application didn’t suddenly become badly written. The workload exposed an inefficiency that was already present.

The ORM Didn’t Lie. It Hid the Cost.

Let’s be precise about the title.

Your ORM isn’t necessarily generating bad SQL. In the example above, each individual SQL statement is reasonable.

The problem is the way the application uses the ORM.

Object-relational mappers make relational data easier to work with by representing tables and relationships as application-level objects. That abstraction is useful, but it can make the cost of accessing related records less obvious.

Consider this TypeORM example:

The repository methods are straightforward. The relationship is expressed through objects rather than handwritten SQL.

But the database still sees a query for the users followed by a query for each user’s projects.

The same pattern can appear in Prisma, TypeORM, Sequelize, Django ORM, Hibernate, and other data-access tools.

The syntax changes. The database workload does not.

This is an important distinction: an ORM can simplify how you express a query without guaranteeing that the overall query strategy is efficient.

A method call that looks like a single operation at the application level may generate multiple SQL statements. And a loop containing a database call can multiply those statements in ways that are easy to overlook during code review.

The right question isn’t simply, “Does this code use an ORM correctly?”

It’s also, “How many database operations does this code generate for a typical request?”

The First Fix: Fetch Related Data Intentionally

Let’s return to the original requirement.

We want to retrieve users and their projects.

We don’t actually need to retrieve each user’s projects independently. We already know the complete set of users we’re interested in.
That gives us a few better options.

Option A: Use a nested relation query

With Prisma, you can request the related projects as part of the same logical query:

Instead of manually fetching projects inside a loop, you describe the response shape you need.

Depending on the ORM version and relation-loading strategy, Prisma may load the related records using a database join or multiple batched SQL queries. Either way, this avoids the original pattern of issuing one independent project query for every user.

That distinction matters.

A nested ORM query doesn’t universally mean one SQL statement. Some ORMs fetch relations using a join; others issue separate queries and combine the results in application code. Some support both strategies.

What matters first is eliminating the repeated per-record lookup. After that, you can evaluate which relation-loading strategy best fits the workload.

This Prisma’s documentation explains the available relation-query strategies and their trade-offs

Option B: Fetch the parent records, then batch the children

Sometimes you need more control over how the data is assembled.

You can retrieve the users first, collect their IDs, and fetch all matching projects in a single additional query.

Assume userId is a numeric field in this example. If your schema uses UUIDs or strings, use the corresponding TypeScript type.

The important part is this filter:

where: { userId: { in: userIds, }, }

Instead of executing one query per user, the application asks PostgreSQL to retrieve projects belonging to the entire set of user IDs.

For a non-empty user list, this approach uses two logical database reads: one for users and one for projects.

The application then groups the projects by userId and assembles the response.

This is a useful pattern when:

You need custom response shaping.
You want separate control over parent and child queries.
The relation-loading behaviour of your ORM isn’t suitable for the endpoint.
You need to reuse the fetched records for additional application-level processing.

There are trade-offs. You now own the grouping logic, and a large list of IDs may require batching or pagination. You also need to ensure that the response doesn’t load an unbounded number of child records.

But the query count no longer grows by one for every user.

That’s the key improvement.

A JOIN Is Not Automatically the Best Answer

At this point, it can be tempting to conclude that every N+1 problem should be fixed with a SQL JOIN.
Often, a join is a good solution. But treating it as a universal rule replaces one simplistic assumption with another.

Consider:

This retrieves users and their projects through a single SQL statement.

For a straightforward one-to-many relationship, it can be an effective solution.

But joins change the shape of the result set.

If one user has ten projects, that user’s columns can appear across ten result rows. If you join multiple one-to-many relationships, the number of intermediate rows can grow dramatically.

For example, a user has 10 projects and 20 notifications. Joining both collections without carefully controlling the query shape can produce up to 200 combinations for that user.

This is sometimes called row multiplication or join explosion.

The database may still execute the query efficiently for a particular workload, but the application can end up processing far more data than it actually needs.

The practical lesson is not to avoid joins. It is to understand what the join produces.

Use a join when the relationship and result shape make sense. Consider separate batched queries when they avoid unnecessary row multiplication or make pagination easier to reason about. Measure both approaches when the workload justifies it.

The objective is not to minimize the SQL statement count at any cost. It is to minimize unnecessary work while preserving the data and consistency your endpoint requires.

Why Adding an Index Doesn’t Fix the Root Problem

Suppose the original query is slow:

That may be the right index for the query, depending on the table size, data distribution, and execution plan.

But the N+1 pattern remains.

If the application retrieves 100 users and issues one project query for each, the database still receives 100 project queries. The index may make those lookups faster, but it doesn’t remove their round-trips or execution overhead.

There is another detail worth remembering: indexes aren’t free. They consume storage and add maintenance work to inserts, updates, and deletes.

An index should support a meaningful access pattern, not compensate blindly for a query strategy that should be redesigned.

A useful debugging sequence is:

Count how many times the query executes per request.
Identify whether the repetitions are necessary.
Change the query shape to batch or load the related data appropriately.
Inspect the execution plan of the remaining important queries.
Add or adjust indexes when the evidence supports doing so.

Use PostgreSQL’s EXPLAIN (ANALYZE, BUFFERS) to investigate query execution, remembering that ANALYZE executes the statement. For statements that modify data, take appropriate precautions and understand the side effects before running it.

Query-plan analysis and query-count analysis answer different questions. You need both when both are relevant.

The GraphQL Trap: One Resolver, One Query, Repeated Many Times

N+1 problems are particularly easy to introduce in GraphQL.

Imagine a GraphQL API that returns users and their projects:

query { users { id name projects { id name } } }

The users resolver fetches the users.

Then the projects field resolver runs for each returned user.

If that resolver performs an independent database query, the request can produce the familiar N+1 pattern.

The confusing part is that each resolver may be perfectly reasonable in isolation.

The users resolver knows how to fetch users. The projects resolver knows how to fetch projects for a user. Both do their jobs correctly.

The inefficiency appears when the GraphQL execution model invokes the projects resolver repeatedly without coordinating those database reads.

One common solution is a DataLoader-style batching mechanism.

Conceptually, the resolver asks for projects for a particular user:

const projects = await projectLoader.load(user.id);

Instead of immediately executing a separate query for every call, the loader collects multiple user IDs and fetches the corresponding projects in a batch.

The batch function might look like this:

The returned array must correspond to the order of the incoming IDs, including empty results. That ordering contract is important for DataLoader implementations.

In production, you would normally use a DataLoader implementation or equivalent batching utility rather than building all of its caching and scheduling behavior yourself.

Also, create loaders with the appropriate request scope when cached results depend on the current user or authorization context. A global loader cache can accidentally reuse data across requests if it’s designed incorrectly.

DataLoader isn’t just a performance trick. It addresses a structural problem: field-level resolvers often need a way to coordinate data access across many related objects.

Why Promise.all() Is Not a Real Fix

One of the most common attempts to fix a slow loop is to make the queries concurrent.

Instead of:

A developer writes:

The second implementation removes the sequential wait between queries.

That can reduce wall-clock latency for small, bounded workloads. But it still issues one query per user.

With 100 users, you’re still generating roughly 100 project queries.

Worse, you’re now attempting to issue them concurrently. Depending on the database pool and workload, this can increase contention, create a queue of waiting queries, and consume resources more aggressively.

Concurrency changes when the work runs. It does not eliminate the work.

There are legitimate reasons to execute independent queries concurrently. The mistake is using concurrency as a substitute for reducing unnecessary database operations.

Before asking, “How can I make these queries run faster?”, ask, “Why am I running so many queries at all?”

Not Every Repeated Query Is an N+1 Problem

A good engineer also knows when not to apply a pattern mechanically.

Imagine you’re processing a small batch of three records. Fetching related data separately might be perfectly acceptable if it makes the code simpler and the performance requirements are met.

Or suppose each item requires a different query with distinct filters, authorization rules, or business logic. Those queries may not be safely reducible to one batch.

The defining concern isn’t simply that a query appears multiple times. It’s that a query is being repeated per result when the underlying data could be retrieved more efficiently as a group.

You should also distinguish N+1 from other database performance problems.

Missing indexes: The database must examine too many rows to answer a query.
Over-fetching: The application retrieves more columns or records than it needs.
Inefficient joins: A query creates excessive intermediate rows or performs expensive operations.
Connection pool exhaustion: Requests wait for database connections to become available.
N+1 queries: The application issues unnecessary additional queries as the number of parent records grows. These problems can occur together, but they require different diagnoses.

A slow endpoint is a symptom, not a diagnosis. Don’t start adding indexes, introducing Redis, or rewriting your ORM queries until you understand which cost is actually dominating the request.

How to Detect N+1 Queries Before Production

The most reliable approach is to observe what the application sends to the database.

Log Prisma queries during development

Prisma supports query-event logging that can help you inspect generated SQL and execution durations.
For example, depending on your Prisma version and client setup:

This is a simplified example of setting up a query listener. In a NestJS application, integrate the listener into your Prisma service or database instrumentation setup rather than creating a separate client for every service.

Avoid indiscriminately logging sensitive parameter values in production. Query logs can expose personal information or other confidential data, and excessive logging can introduce its own performance overhead.

Look for repeated query shapes

Suppose your logs contain:

`SELECT ... FROM "User";

SELECT ... FROM "Project"
WHERE "userId" = $1;

SELECT ... FROM "Project"
WHERE "userId" = $1;`

The repeated query shape is a clue.

The parameter changes, but the SQL structure stays the same. If the same route triggers this pattern repeatedly, investigate whether the query is being executed once for every parent record.

Don’t assume that repeated SQL automatically means N+1. A query may legitimately execute multiple times. Correlate the events with the request, route, and data-access code.

Measure query count per request

Execution duration alone doesn’t tell the full story.

A route that executes 40 queries taking 2 milliseconds each may look healthy when you inspect individual query durations. Yet the route could be doing far more database work than its response requires.

Useful measurements include:

Number of database queries per request.
Repeated query shapes and execution counts.
Total database time per request.
Endpoint latency, including p50, p95, and p99.
Connection pool wait time and utilization.
Rows returned and, where available, rows examined or read.

Test with realistic data volumes

An N+1 problem may be invisible when your test database contains only two users.

With two users, the endpoint performs three queries. That may seem harmless.

With 200 users, the same code performs 201 queries.

Performance tests should use representative record counts and relationships. Where practical, test query counts as well as response time. A test that verifies only the returned JSON can pass even when the implementation generates hundreds of unnecessary queries.

A Practical Checklist for Reviewing Database Access

When reviewing a NestJS service, GraphQL resolver, or repository method, ask:

1. Am I querying inside a loop?

Look for database calls inside for, for...of, map, forEach, or other repeated execution paths. Not every occurrence is wrong, but each deserves scrutiny.

2. Can I fetch the related records in one batch?

If you already have a collection of IDs, consider a query using IN, an ORM’s nested relation loading, or a DataLoader-style batching mechanism.

3. Am I returning only the data the endpoint needs?

Use select or the equivalent to avoid loading large text fields, unnecessary relations, or entire entities when the response requires only a few fields.

4. Is the response bounded?

Pagination matters. Fetching all users and all their projects in one giant query can replace an N+1 problem with an unbounded data-loading problem.

5. Does the chosen loading strategy fit the relationship?

A join may be effective for one relation but expensive when several large collections are loaded together. Compare the query shapes and actual execution costs.

6. Have I measured the result?

Count the queries before and after the change. Compare endpoint latency and database resource usage under representative load.

7. Is the data access still correct?

Optimization must preserve authorization, filtering, ordering, pagination, and any required consistency guarantees. A faster query that returns the wrong records is not an optimization.

Final Thoughts: Your ORM Is Only as Smart as the Queries You Ask It to Make

N+1 queries are frustrating because they rarely look like a serious engineering mistake at first.

The code is readable. The relationships are modeled correctly. The endpoint returns the expected response.

The problem is hidden in the execution pattern.

An ORM can make database interactions easier to express, but it cannot remove the need to understand how those interactions translate into actual database work.

And the fix isn’t always to write raw SQL, add an index, introduce a cache, or force every relation into a join. Sometimes, the most effective improvement is simply to stop asking the database the same question one record at a time.

Think about the workload your code creates, not just the code you write.

When an endpoint becomes slow, don’t stop at asking whether each query is efficient. Ask whether all those queries need to exist in the first place.

Because the fastest unnecessary query is the one your application never sends.

How to Choose a Database for Your Next SaaS: A Practical Framework

Nsikan Patrick Adaowo — Thu, 22 Oct 2026 19:45:39 +0000

“Which database is best for my SaaS?”

This is a reasonable question, but it’s also the wrong place to start.

PostgreSQL, MongoDB, Redis, and other databases solve different problems, operate with different trade-offs, and excel under different workloads. Comparing their features without understanding your application is like choosing an architecture before defining what the system needs to do.

Will your application perform complex joins? Process thousands of writes per second? Maintain strict consistency across financial records? Or retrieve flexible documents with minimal transformation?

Each answer changes the decision.

There is no universally best database. There is only the database whose trade-offs make the most sense for the system you’re building.

The challenge is knowing how to evaluate those trade-offs before committing to a technology. This article discusses what you need to know before picking a database for your SaaS product.

Start With the Product, Not the Database

Imagine you’re building a subscription platform for small online stores. Each store can manage products, orders, customers, and staff. Later, you may add reporting, search, and integrations.

It’s tempting to begin with a technology list:

PostgreSQL for data.
Redis for caching.
Elasticsearch for search.
Kafka for events.

But that is not architecture yet. It’s a collection of tools—and every extra system brings its own deployment, monitoring, backup, and failure story.

First, describe the product’s important data and behaviours:

A customer places an order.
The system reserves or reduces inventory.
A payment provider confirms or rejects payment.
Store staff update order status.
The owner views sales reports.
A customer searches the store’s products.

Now ask which of these behaviours must be correct even when requests overlap, a service restarts, or an external provider is slow.

That question brings you closer to the database decision than “What’s popular right now?”

Step 1: Write Down Your Invariants

An invariant is a rule that must remain true for the system to be correct.
For the store platform, examples might include:

An order must belong to the correct tenant.
A completed payment must not be recorded twice.
An order must not reserve more stock than is available, unless backorders are an explicit feature.
A staff member must not access another store’s data.
A refunded payment must remain connected to its original transaction.

These rules are more important than your expected traffic. Traffic can grow; a broken financial invariant can damage trust from day one.

For each invariant, ask where it should be enforced:

In a database constraint or transaction?
In application code?
At a service boundary?
In a reconciliation process that detects and repairs discrepancies?

Usually, the answer is not “only one place.” Critical rules often need layered protection. But if the database can enforce an invariant directly, you avoid relying on every code path to remember it.

For example, a unique constraint on a payment provider’s transaction ID can help prevent duplicate payment records. A transaction can ensure that creating an order and reserving its inventory happen together within the database’s supported boundary.

The lesson is not that one database makes correctness automatic. It’s that your choice should make your important rules practical to enforce.

Step 2: Choose for Your Access Patterns

Understanding your invariants is only half the equation. You also need to understand how your application will retrieve and modify data.
Two applications can have nearly identical entities but require different database designs because their access patterns differ.

Consider a task management application. Its most frequent query might retrieve a user’s open tasks, ordered by due date.

Another application might mostly retrieve a complete task document by ID.

The first workload involves filtering and sorting across a set of records. The second may be dominated by direct lookups.

Those differences affect indexing, query design, and sometimes the appropriate data model.

List the Queries That Matter

A data model should serve the ways the product reads and writes data. Write down the important queries before choosing a storage model.

For our SaaS, that list might include:

Load a store’s products by category.
Fetch an order and its line items.
List recent orders for one store, sorted by creation time.
Find a payment by its provider transaction ID.
Show a customer’s order history.
Search products by name.
Summarize daily sales for a date range.

For each query, note:

How often it runs.
How fresh its result must be.
Whether it needs joins or aggregation.
How much data it may scan.

Whether it must work across tenants or stay inside one tenant.

This is where database models start to look different.

A relational database can make connected records and transactional updates natural. A key-value or document database may be a strong fit when the access patterns are known and can be served efficiently by specific keys and indexes. A search engine can support rich text search, but it does not need to become the authoritative home for orders and payments.
Don’t ask only, “Can this database store the data?” Almost all modern databases can store your data. Ask, “Can it serve the important queries without forcing us to build a second database in application code?”

What if the access patterns change?

Your SaaS will evolve. A feature that originally required retrieving a single record may later need filtering, sorting, reporting, or cross-entity searches.

You cannot predict every future query. But you can identify the application’s core access patterns and avoid choosing a database that makes them unnecessarily difficult.

This is why workload analysis should happen before technology selection, not after performance problems appear.

Step 3: Understand the Difference Between SQL and NoSQL

SQL versus NoSQL is one of the most common database debates. It is also one of the least useful starting points for choosing a database.

SQL databases typically offer a relational model, declarative querying, and strong integrity features. NoSQL is a broad category that includes document databases, key-value stores, wide-column databases, and other systems with different data and access models.

These are not two interchangeable technologies with a single universal winner.

They represent different design choices.

Relational databases

PostgreSQL and MySQL are common choices for SaaS applications involving related entities, transactional workflows, flexible queries, and constraints.

They are particularly attractive when the application needs to join related data, enforce uniqueness, maintain referential integrity, and evolve its query requirements over time.

For many conventional SaaS products, PostgreSQL is a strong starting point because it supports a broad range of application workloads without requiring the team to operate several different storage systems.

Document databases

MongoDB can be a good fit when the document is a natural unit of storage and retrieval, document structures vary meaningfully, and the application’s access patterns align with its document model.

But flexibility doesn’t mean that relationships, consistency, and query complexity disappear. Those concerns still exist; they simply need to be addressed according to the database’s model and capabilities.

Key-value stores

Redis is designed for low-latency access to values by key, with additional data structures and capabilities. It is commonly useful for caching, ephemeral state, rate limiting, and certain queue or coordination patterns.

It may also serve as a primary datastore for specific workloads, but that decision requires evaluating persistence, recovery, durability, and data-model requirements carefully.

Choosing Redis because it is fast doesn’t automatically make it the right system of record for customer accounts, invoices, and other business-critical data.

The decision isn’t about which category wins

A relational database can handle flexible data. A document database can support relationships and transactions within its supported model. A key-value store can be appropriate for more than simple caching.

The real question is how well each candidate supports your requirements, including the operational costs and constraints it introduces.

Avoid making the decision based on labels alone.

Step 4: Choose Consistency Deliberately

Not every piece of data needs the same consistency guarantees. But some operations cannot tolerate ambiguous or conflicting outcomes.

If a store owner changes a product description, it may be acceptable for search results to update a little later. If a customer pays for an order, the system needs a clear and reliable way to record that outcome.

That suggests a useful distinction:

Authoritative data is where the system records the truth.
Derived data is built from that truth to make particular reads faster or more convenient.

For example:

The order and payment records may live in the primary transactional database.
Product search documents may be copied into a search index.
Sales summaries may be computed into reporting tables or an analytics store.
Frequently requested product details may be cached.

The search index can lag behind the product database. That may be acceptable if you’ve chosen that behaviour deliberately. The payment record should not be treated as “eventually correct” without a clear reconciliation and customer-support plan.

This connects directly to the earlier point: consistency is not merely a technical setting. It becomes a product promise.

Step 5: Evaluate Scale Without Prematurely Optimizing for It

Developers sometimes choose a database for the scale they hope to reach rather than the workload they actually have.

A new SaaS might adopt a distributed database because it expects millions of users. Another might introduce multiple databases, a cache, a search engine, and a message broker before the first customer arrives.

These decisions can create operational overhead long before they deliver meaningful value.

A better approach is to distinguish between the scale you need today, the growth you reasonably expect, and the requirements that would force a different architecture later.

Think beyond the number of users

User count alone is a poor measure of database workload.

Ten thousand users who occasionally update records may create less database pressure than a few hundred users generating thousands of events per second.

Evaluate factors such as:

Read and write throughput.
Peak traffic and burstiness.
Dataset size and growth rate.
Query complexity and data distribution.
Latency requirements.
Replication and availability requirements.
Backup and recovery objectives.
Retention and archival needs.

For many early-stage SaaS products, a well-designed PostgreSQL database on a managed service is sufficient to support substantial growth.

That doesn’t mean PostgreSQL is always the right answer or that it scales indefinitely without architectural changes. It means you should measure your requirements before introducing complexity.

You can often extend a sound starting architecture through better indexing, query optimization, connection pooling, caching, read replicas, partitioning, or workload separation.

Each option has trade-offs, and none is a substitute for understanding the bottleneck.

Don’t pay the complexity cost of a distributed architecture until your requirements justify it—or you have a clear, concrete reason to adopt it early.

Step 6: Account for Operational Complexity

A database doesn’t exist only in your application code. Someone has to run it, monitor it, secure it, back it up, restore it, and respond when something goes wrong.

For an early-stage SaaS team, those responsibilities can matter as much as query performance.

Consider two database options.

One offers excellent performance for a specialized workload but requires your team to manage clustering, replication, upgrades, and recovery.

The other is a managed service that provides automated backups, monitoring, routine maintenance, and a straightforward recovery process.

The specialized option might be justified if its capabilities are essential. Otherwise, the managed service could be the better engineering decision—even if it isn’t the theoretical winner on every benchmark.

When evaluating operational fit, ask:

Can we back up and restore the database reliably?
How difficult is it to monitor query performance and resource usage?
What happens when the database becomes unavailable?
How do we handle schema migrations safely?
What are the limits of our managed service?
Can the team diagnose problems with its current skills?
What happens if we need to migrate away from this provider?

The last question deserves particular attention.

Portability is not just about whether a database can export data. It also involves query languages, database-specific features, extensions, migration tooling, and assumptions embedded in application code.

Using a familiar database doesn’t eliminate operational risk, but it can reduce the number of unfamiliar problems your team must solve simultaneously.

For a small team, that reduction in complexity is often valuable.

Step 7: Calculate the Total Cost, Not Just the Hosting Bill

Database costs extend beyond the monthly invoice from your cloud provider.

A database may have inexpensive storage but require more compute for your query workload. Another may offer attractive performance but incur costs for replication, backup retention, data transfer, or specialized infrastructure.

There is also the cost of engineering time.

A database that requires substantial custom code to support ordinary application operations can be more expensive in practice than one with a higher hosting bill.

Your evaluation should include:

Infrastructure costs

Compute, storage, and I/O.
Replication and high availability.
Backups and retention.
Data transfer and regional deployment.
Managed-service pricing and usage limits.

Engineering costs

Development and migration effort.
Query optimization and maintenance.
Monitoring and incident response.
Specialized operational knowledge.
Future changes to the data model.

For an early-stage product, operational simplicity and predictable costs may be more important than squeezing out the last bit of performance.

As the workload grows, that balance may change.

The point isn’t to predict the exact lifetime cost before launch. It’s to identify the major cost drivers and avoid a choice that makes your likely workload unnecessarily expensive.

Step 8: Use Specialized Databases Only When They Solve a Real Problem

A growing SaaS may eventually benefit from more than one database technology.

For example, you might use:

PostgreSQL as the primary system of record.
Redis for caching or short-lived state.
A dedicated search engine for sophisticated full-text search.
An analytical store for large-scale reporting.
A vector-search capability for semantic retrieval in an AI-powered feature.

These systems serve different purposes. But adding them also means more infrastructure, more failure modes, more monitoring, and more data synchronization to manage.

Imagine your SaaS needs semantic search over product descriptions. That requirement alone doesn’t mean you must immediately adopt a separate vector database.

Depending on the scale and retrieval requirements, PostgreSQL with the pgvector extension may be sufficient. A dedicated vector database may become attractive when its performance, indexing, filtering, scaling, or operational characteristics better fit the workload.

The same reasoning applies to caching and search infrastructure.

Don’t add a technology because it appears in the architecture of a popular company. Add it because you can identify the problem it solves, explain why your existing system is insufficient, and justify the additional complexity.

This is particularly important for AI-powered SaaS products. Embeddings, retrieval, conversation history, and background inference jobs introduce additional workloads, but they don’t automatically require replacing your primary relational database.

Start with the simplest architecture that meets the actual requirements. Expand when evidence or a concrete requirement justifies it.

A Practical Framework for Making the Decision

You can use this framework when starting a new SaaS project or reconsidering an existing database.

Step 1: Define the application’s core operations

List the reads, writes, filters, aggregations, and background jobs that matter most.

Don’t stop at entities such as User, Order, and Product. Describe the operations the application must perform on them.

Step 2: Identify the data guarantees

Determine which records must remain consistent, which relationships need enforcement, and which operations must be atomic.

Document uniqueness rules, transactional boundaries, concurrency risks, and recovery requirements.

Step 3: Estimate the workload

Make reasonable estimates of traffic, data volume, write frequency, latency, and growth.

Separate current requirements from speculative future requirements.

Step 4: Shortlist suitable database candidates

Choose a small number of technologies that can support your core workload.

For a conventional transactional SaaS, PostgreSQL is often a sensible first candidate. Consider alternatives when your data model, access patterns, or specialized requirements give them a meaningful advantage.

Step 5: Test the critical operations

Build a small proof of concept for your most important or difficult queries.

Use realistic data distributions, inspect query plans, and test the consistency behaviour of critical operations. Benchmarks using tiny datasets or unrealistic access patterns can be misleading.

Step 6: Evaluate operational and financial costs

Compare managed-service options, backup and recovery capabilities, monitoring, migration complexity, and expected infrastructure costs.

Include the team’s ability to operate the system reliably.

Step 7: Document the trade-off

Record why you chose the database, which alternatives you considered, what assumptions informed the decision, and which signals would cause you to reconsider it.

This makes the decision easier to revisit when the product evolves.

A Sensible Starting Point for Your Next SaaS Product

For your next SaaS product, a practical initial architecture might look like this:

1. PostgreSQL as the primary database

PostgreSQL is a strong starting candidate because the product contains relational data, transactional workflows, constraints, and a variety of query patterns.

It can support the core entities, transactional operations, filtering, joins, reporting queries, and flexible attributes where JSONB is useful.

Prisma can provide a convenient TypeScript data-access layer, while NestJS can organize the application logic and transaction boundaries.

2. Redis when a clear use case appears

You might later introduce Redis for frequently accessed cached data, rate limiting, or short-lived state.

But the application doesn’t need Redis simply because it has a database. First identify a workload where caching or low-latency key-based access provides a measurable benefit.

3. Specialized infrastructure when requirements justify it

If reporting workloads begin interfering with transactional queries, consider separating analytical workloads. If full-text or semantic search outgrows the existing solution, evaluate a dedicated search system or vector database.

Those decisions should follow actual requirements, not precede them.

What makes this a good decision?

It isn’t that PostgreSQL is always the best SaaS database.

It’s that PostgreSQL fits the stated requirements, supports a broad range of the application’s operations, and allows the team to start with a relatively simple architecture.

This is not a universal prescription. It is a reasonable starting shape for a product with connected business data, transactional workflows, and a small team that wants to keep its operational surface manageable.

The important part is the boundary: the primary database owns the authoritative business records; specialized systems serve specialized workloads.

A Decision Checklist

Before committing to a database, answer these questions:

What are the system’s most important invariants?
Which operations need to be atomic?
What are the top queries the product must serve?
Which reads can tolerate stale or derived data?
How will tenant isolation work?
What backup and restore process can the team actually run?
What is the likely first scaling bottleneck?
Which extra components are needed now, rather than merely imaginable?
What concrete signal would make us revisit this decision?

If these questions have clear answers, you’re not choosing a database based on hype or habit. You’re making a decision that fits the product and the team.

The Goal Isn’t a Perfect Choice

There is no database that makes every workload simple, every query fast, and every failure harmless.

The goal is to choose a system whose trade-offs you understand—and whose constraints match the product you’re building now. Then keep the decision visible as the product changes.

A database decision is not a lifetime contract. But changing it later is rarely just swapping a connection string. It can mean rewriting queries, moving data, changing consistency guarantees, updating operational practices, and revisiting service boundaries.

So don’t choose a database because someone said it scales. Don’t reject one because it might not scale to a future you haven’t reached.

Start with the invariants. Map the access patterns. Be honest about your team’s operational capacity. Then choose the simplest architecture that supports the product’s real requirements.

That’s not under-engineering. It’s making the decision on purpose.

Why Your Database Design Should Start with Access Patterns — Not Tables.

Nsikan Patrick Adaowo — Sun, 18 Oct 2026 17:49:44 +0000

There’s a familiar way developers approach database design.

Identify the entities. Create the tables. Define the relationships. Add a few indexes. Connect everything to an ORM and start building endpoints.

Users need a table. Projects need a table. Tasks need a table. Each task belongs to a project, so we add a foreign key. Everything looks clean, and the application starts working.

Then the requirements become more realistic.

You need to retrieve a user’s most recent tasks across multiple projects. You need to display the latest activity in a workspace. You need to filter tasks by status, sort them by priority, and paginate the results. You need to generate monthly reports without slowing down ordinary requests.

Suddenly, the schema that looked perfectly reasonable starts producing complicated queries, unnecessary database round trips, and performance problems that are difficult to explain.

The instinct is often to add another index, introduce caching, or restructure a few tables.

Sometimes those are the right solutions.

But most times the problem started much earlier: you designed the database around the entities you could identify, not the operations your application needed to perform.
A database schema isn’t just a representation of your business objects. It also determines how efficiently the application can retrieve, update, and maintain the data those objects represent.

This is why good database design starts with access patterns.

Your Entities Tell You What Exists. Access Patterns Tell You What Matters.

Imagine you’re building a project management application.

At the domain level, you identify a few obvious entities:

Users
Workspaces
Projects
Tasks
Comments
Activity logs

A reasonable relational model might connect them like this:

This gives you a useful starting point. You understand the major entities and how they relate.

But it doesn’t tell you enough to design the database well.

Consider what the application actually needs to do.

A user opens a workspace dashboard and expects to see its projects, outstanding tasks, and recent activity. Another user opens a project and expects to see its tasks, ordered by priority. A manager wants all overdue tasks assigned to a particular team member. An administrator wants an activity report for the last 30 days.

Each operation has a different access pattern.

For example:

These operations matter because they describe how the database will actually be used.

A schema can accurately represent every entity and relationship yet still make common operations unnecessarily expensive.

The reverse is also possible. A schema designed to optimize one query might make other operations difficult or introduce data consistency problems.

The objective isn’t to make every query equally fast. That’s rarely realistic.

It’s to understand which operations matter most, what they require, and how the data model can support them without creating unacceptable trade-offs elsewhere.

Your entities describe the domain. Your access patterns reveal the demands your database must satisfy.

Both are necessary, but they answer different questions.

Start with the product’s questions

An access pattern is a recurring way the application reads or changes data to support a user journey, business rule, or background task.

Examples:

Find a user by email during login.
Load a tenant’s active projects, newest first.
Find tasks assigned to a user and sort them by due date.
Retrieve an order and its line items.
Check whether a payment webhook has already been processed.
Find subscriptions due for renewal.
Count unread notifications.
List events for a device within a time range.

These are not details to postpone until performance becomes a problem. They are part of the system’s requirements.

For each important access pattern, ask:

What information does the application have when it makes this query?
What data must it return?
How often will it run?
How many records might it touch?
How quickly must it respond?
Must the result reflect the latest write?
What should happen if the operation is repeated?

Those answers shape the data model, indexes, constraints, and sometimes the database itself.

Design Around Real Queries, Not Imaginary Future Requirements

Before creating tables, write down the operations the application must support.

Not every hypothetical feature you might build someday. Start with the operations that are necessary for the current product.

Suppose one of the most common operations in our project management application is:

Show the 20 most recently updated tasks in a project, including their titles, statuses, and assignees.

That sentence already tells us a lot.

We need to:

Restrict the results to one project.
Order tasks by their last update.
Return a limited number of records.
Retrieve the fields needed by the interface.

Include assignee information without creating unnecessary database round trips.

We can express the operation in SQL:

Notice what we did before creating an index or changing the schema.

We identified the actual query.

From this query, we can begin making informed decisions about:

Which columns need to exist.
Which relationships must be represented.
Which fields are used for filtering and sorting.
Whether an index could support the operation.
Which fields the application actually needs to retrieve.

The query also reveals an important detail: updated_at alone may not provide a deterministic order when multiple tasks have the same timestamp.

Adding id as a tie-breaker gives us a stable ordering for pagination.

This isn’t an argument for writing every SQL query before designing every table. It’s an argument for understanding the operations the schema is supposed to support.

You can still use entity diagrams, domain models, and normalization techniques. The difference is that you validate those designs against real access requirements rather than assuming the model will automatically produce efficient queries.

Build an access-pattern inventory

For a real project, I would document the important operations in a small table:

These ratings are illustrative, not universal. A financial report may require stricter consistency than a project dashboard, while a dashboard may have tighter latency requirements.

The point is to make the trade-offs explicit.

A frequently executed query deserves more attention than an administrative operation run once a month, unless that less frequent operation has unusually high business impact.

Database design becomes more deliberate when every important part of the schema can be connected to a real requirement.

Your Access Patterns Should Influence Your Indexes

Indexes are one of the clearest examples of why access patterns matter.

Developers sometimes create indexes because a column feels important, because it’s frequently mentioned in the application, or because they expect the database to become slow eventually.

But an index is useful when it helps the database execute a workload more efficiently.

Let’s return to our task query:

A potential index is:

Why these columns, and why this order?

The query first restricts rows to a particular project_id. Within that project, it needs tasks ordered by updated_at and then id.

The composite index reflects that sequence.

PostgreSQL may be able to use the index to locate the project’s tasks in the required order and stop after retrieving enough matching rows.

The actual execution plan still depends on the table’s size, data distribution, selectivity, and other factors. An index doesn’t guarantee that PostgreSQL will choose it.

But we have a reason for creating it: it supports a known access pattern.

Why column order matters

Consider this alternative:

This index has the same columns, but a different leading column.

It may be useful for queries that primarily scan tasks in update-time order. However, it is generally less suitable for efficiently locating one project’s range of tasks in the same way as the first index.

For a B-tree index, leading columns matter because they determine how effectively the index can narrow the search.

That doesn’t mean every index must start with the most frequently mentioned column. It means the index must be evaluated against the predicates and ordering of the queries you need to support.

Now consider the cost.

Every additional index consumes storage. Inserts and deletes must maintain it, and updates to indexed columns can require additional index work.

An index can make one query faster while making write operations more expensive.

This is why blindly indexing every filterable field isn’t a good strategy.

A better process is:

Identify an important query.
Inspect its execution plan with EXPLAIN.
Determine whether scanning, sorting, joining, or another operation is expensive.
Design an index that targets the actual bottleneck.
Measure the result using realistic data.

For example:

EXPLAIN ANALYZE executes the query and reports actual execution details, while BUFFERS provides information about data access through PostgreSQL’s buffer system.

Be careful when running it against production queries that have side effects: EXPLAIN ANALYZE executes the statement. For mutating statements, use an appropriately controlled environment or a safe transaction strategy.

Also remember that a query plan measured on a tiny development database may not predict its behaviour against millions of production rows.

Indexes should be a response to observed or well-understood access patterns, not a substitute for understanding them.

The Same Data Can Need Different Models for Different Access Patterns

Here’s where database design becomes more interesting.

Suppose our application stores workspace activity:

TaskCreated
TaskAssigned
TaskCompleted
CommentAdded
MemberInvited

Each event records what happened, when it happened, and which workspace it belongs to.

A natural table might look like this:

This is a reasonable starting point for a workspace activity feed.

But what if the product introduces several different requirements?

Show the latest 50 events in a workspace.
Retrieve the history of one particular task.
Count completed tasks per day.
Search activity by actor.
Generate a monthly report grouped by event type.

These are different workloads against the same underlying information.

The workspace feed is optimized around a workspace and time range. Task history is centered on an entity. Reporting requires aggregation. Search may require text indexing or a separate search system if the requirements grow sufficiently complex.
One table and one index will not necessarily serve every workload optimally.

This doesn’t mean you immediately need multiple databases or duplicated data. It means you should recognize that a data model is a set of trade-offs across multiple operations.

You might add another index if task-history queries become important:

If reporting becomes expensive, you might introduce a summary table or a materialized view. If text search becomes a major workload, you might evaluate PostgreSQL’s full-text search before introducing a dedicated search engine.

The appropriate response depends on query frequency, latency requirements, data volume, and the freshness guarantees the product needs.

What about denormalization?

Sometimes you deliberately store information in more than one place because the read workload justifies it.

Imagine a dashboard that displays the total number of open tasks in each project.

One option is to calculate the count every time the dashboard loads:

For a small application, this may be perfectly adequate.

But if the task table grows significantly and this aggregation becomes a frequent, expensive operation, you might maintain a project-level counter or a summary table.

Now the dashboard can retrieve a precomputed value rather than repeatedly aggregating the entire matching dataset.

The trade-off is that the summary must remain correct.

If a task changes from OPEN to DONE, the count must be updated. If a transaction fails, the counter must not drift away from the underlying data. If events are processed asynchronously, the summary may temporarily lag behind the source records.

A denormalized model is not simply a faster version of a normalized model. It exchanges some computation at read time for additional complexity in maintaining the data.

This is a decision to make when you understand the workload and can justify the cost.

Normalize to protect the integrity of your data. Denormalize when a demonstrated access requirement justifies the additional consistency work.

Don’t duplicate data merely because you assume reads will eventually become slow.

ORMs Don’t Remove the Need to Think About Queries

Working with an ORM makes database access more convenient. It doesn’t make the underlying query patterns disappear.

Consider a NestJS service using Prisma:

This is a reasonable implementation of the query we discussed earlier.

It filters by project, orders the results deterministically, limits the result set, and retrieves only the assignee fields needed by the application.

But an ORM call isn’t automatically efficient just because it looks clean.

Consider another implementation:

This pattern can produce an additional query for each task with an assignee.

If the initial query returns 20 tasks, the service could issue up to 21 queries instead of retrieving the necessary data through a more efficient access strategy.

This is a version of the N+1 query problem.

The issue becomes more significant when the pattern appears inside nested loops, list endpoints, or other high-traffic operations.

ORMs provide tools for loading relations, selecting fields, batching queries, and managing transactions. The exact SQL generated depends on the ORM, its configuration, and the query being executed.

The important thing is to understand what happens beneath the abstraction.

A practical ORM workflow

When designing an endpoint, ask:

Which records does this operation actually need?
Which fields should be returned?
Which relationships must be loaded?
Can the data be retrieved in a single efficient query, or is a small number of targeted queries preferable?
Will this operation trigger repeated queries for every returned record?
Does the query have an appropriate index?

You should also inspect the SQL generated by the ORM when performance matters.

Abstraction is useful when it makes code easier to maintain. It becomes a problem when it hides a costly access pattern that nobody is monitoring.

An ORM can simplify how you express a query. It cannot make a poorly designed query free.

Pagination Is a Database Design Problem, Too

Pagination looks like an API concern, but the way you paginate data can have a significant impact on database performance.

Imagine the application has hundreds of thousands of tasks in a workspace.

A common approach is offset pagination:

This asks the database to skip the first 10,000 rows in the ordered result and return the next 20.

Offset pagination is straightforward and works well for many applications. But as the offset grows, the database may need to walk through an increasingly large number of index entries or rows before it can return the requested page.

Large offsets can therefore become expensive.

There is another concern: if records are inserted, deleted, or reordered between requests, users may see duplicate or missing items as they navigate through pages.

For long lists, feeds, and other workloads where users move forward through a changing dataset, keyset pagination can be a better fit.

Use the last record as a cursor

Suppose the previous page ended with a task whose updated_at was 2026-10-10 10:00:00 and whose ID was task_123.

The next page can request records after that position in the descending order:

Here, $2 is the timestamp of the last record from the previous page, and $3 is its ID.

Because both ordering columns are descending, the row comparison selects records that come after the cursor in that ordering, assuming the columns are non-null and the cursor values use the same ordering semantics.

The composite index from earlier can support this access pattern:

This lets the database seek into the ordered index near the cursor rather than repeatedly skipping a large offset.

There are still important details to consider.

The ordering columns should form a deterministic order, the cursor should encode the relevant values reliably, and nullable columns require additional care. If updated_at changes while a task is being paginated, that task can move relative to the cursor. Keyset pagination reduces some problems associated with offset pagination, but it does not automatically provide a consistent snapshot across multiple HTTP requests.

For a feed where stable traversal is important, you may need an immutable ordering key, a snapshot boundary, or a different consistency strategy.

Also, if users need to jump directly to page 500, offset pagination may be more convenient.

The right choice depends on the product.

The important lesson is that pagination isn’t just about returning a subset of records. It’s about how the database finds that subset, how records are ordered, and what happens when the dataset changes.

Access Patterns Must Not Override Data Integrity

At this point, it might sound as if every table should be designed around the fastest possible query.

That would be another mistake.

Access patterns are a starting point for understanding the workload, not permission to ignore the integrity of the underlying data.

Suppose our application stores a task’s status in a tasks table and also maintains a separate summary table containing the number of open tasks per project.

The summary makes dashboard reads cheaper.

But now a task changes from OPEN to DONE.

If the task update succeeds and the summary update fails, the two representations disagree.

You have improved the read path but introduced a correctness problem.

There are several ways to address this, depending on the system.

For a small summary maintained inside PostgreSQL, you may update the task and the counter within the same transaction. For an asynchronously maintained projection, you may use reliable event processing, idempotent handlers, and reconciliation jobs to detect or repair inconsistencies.

These are different consistency models, with different operational costs.

The same principle applies to normalization.

If a customer’s address is stored in several tables, changing the address may require updating multiple records. If those copies are intended to represent the same current value, you need a strategy for keeping them consistent.

But not every duplicated value is a mistake.

An order item often stores the price agreed upon when the order was placed, even though the current product price may change later. That value is a historical snapshot, not an accidental duplicate.

Understanding the business meaning of data is just as important as understanding how it is queried.

Before denormalizing, ask:

Is this value authoritative or derived?
Can it change independently of its source?
How fresh must the derived value be?
What happens if an update or event is processed twice?
Can the application recover from a failed update?
How will the system detect inconsistent data?

A fast query is not an improvement if it makes the application return incorrect answers.

The goal is not to optimize access patterns at any cost. It’s to balance efficient data access with the correctness guarantees the application requires.

A Practical Workflow for Access-Pattern-Driven Design

You don’t need a complicated process to apply these ideas. You need a deliberate one.

Step 1: Identify the core domain entities

Start with the things the application needs to represent: users, orders, products, workspaces, tasks, payments, or whatever makes sense for your domain.

Define their relationships and the business rules that must hold.

This gives you the foundation of the model.

Here’s a workflow you can use when designing a backend database.

Step 2: List the important application operations

Write down the reads and writes behind the major user journeys and background jobs.

For example:

Load a customer’s recent orders.
Retrieve the items in an order.
Reserve inventory.
Find overdue tasks for a project.
Display a workspace activity feed.
Calculate monthly subscription usage.

Avoid vague requirements such as “the system needs to retrieve tasks.” Specify the filters, ordering, limits, and related data that the operation requires.

Step 3: Turn important operations into queries

Express the operations in SQL or in the ORM you use.

You don’t need to implement every query completely at the beginning. But you should understand what the database will need to do.

For reads, consider filtering, sorting, joins, aggregation, and pagination.

For writes, consider constraints, atomic updates, transaction boundaries, and concurrent operations.

Step 4: Design the schema and constraints

Now create the tables, relationships, data types, foreign keys, unique constraints, and other rules that reflect the domain.

Use normalization where it helps prevent unwanted duplication and update anomalies.

Where a particular access pattern calls for a different representation, evaluate the trade-offs deliberately.

Step 5: Add indexes based on query requirements

Review the most important queries and identify which indexes could support them.

Pay particular attention to composite indexes, column order, filtering, sorting, and pagination.

Don’t forget that indexes have write and storage costs.

Step 6: Test with realistic data

A query that works quickly against 100 rows may behave very differently against 5 million.

Populate your database with representative data volumes and distributions. Run EXPLAIN ANALYZE, inspect buffer usage, and compare query behavior before and after changes.

Test concurrent writes when the application relies on inventory reservations, financial operations, uniqueness, or other important invariants.

Step 7: Measure, revise, and document

Use query logs, application metrics, and database monitoring to understand what happens in production.

If the workload changes, revisit the design.

Perhaps a new dashboard makes a previously unimportant query critical. Perhaps a summary table is now justified. Perhaps the existing index is sufficient, and the real problem lies in connection management or repeated application queries.

Document the reason behind important design decisions so the next engineer understands what the schema is optimized for and which trade-offs it makes.

Database design is not a one-time exercise. It evolves as the application’s workload evolves.

The cost of designing without access patterns

Slow queries

A query may require scanning millions of rows because no suitable index exists.

For example:

Without a suitable index, the database may scan many rows to find matching orders.

PostgreSQL’s query planner chooses between scan strategies such as sequential scans, index scans, and bitmap index scans based on the query structure and data properties.

The right plan depends on the query and the data.

If you do not understand the query, you cannot design the right index.

Too many indexes

Adding an index to every column may seem safe, but indexes are not free.

They consume storage and must be maintained during inserts, updates, and deletes. PostgreSQL documentation explicitly notes that indexes improve retrieval speed but add overhead to the database system as a whole.

A schema with too many indexes can:

Slow down writes.
Increase storage cost.
Complicate migrations.
Confuse the query planner.
Create maintenance burden.

Design indexes around measured access patterns, not around every possible query.

Expensive joins

If two pieces of data are always read together, storing them separately may create unnecessary joins.

For example, if every product page needs product details and its primary image, a design that requires a join for every page load may be less efficient than a design that stores or projects the image reference alongside the product.

But this does not mean you should duplicate everything.

Denormalization should be deliberate.

Data integrity problems

Access patterns also reveal constraints.

For example:

A user should have only one active subscription.
A backup code should be used only once.
A payment reference should be unique.
A task must belong to a project.
An invoice item must reference an invoice.
A tenant-owned record must include a tenant ID.

These rules should be represented in the schema, not only in application code.

Final Thoughts: Don’t Just Model Your Data. Model How You’ll Use It.

A well-designed database isn’t simply one with clean tables, sensible relationships, and a handful of indexes.

It’s one whose structure supports the operations the application needs to perform while preserving the integrity of its data.

That’s why starting with entities alone isn’t enough.

You need to understand the reads, writes, filters, sorts, joins, transactions, and reports that will shape the database’s workload. Those operations reveal where indexes matter, where normalization helps, where denormalization might be justified, and where an apparently simple endpoint could become an expensive production query.

You don’t need to optimize for every imaginable future requirement. You don’t need to introduce specialized databases before you have a reason. And you certainly don’t need to sacrifice correctness for a benchmark.

Start with the domain. Understand the access patterns. Design the schema to support both. Then measure the result and let real workload evidence guide your next decision.

The best database schema isn’t the one that looks the cleanest on a diagram. It’s the one that represents your domain correctly and supports the way your application actually works.

Design for the queries your system needs, not just the tables it contains.

Your Database Is an Architectural Decision. Not Just Storage.

Nsikan Patrick Adaowo — Sat, 10 Oct 2026 14:15:06 +0000

When developers start a new project, the database is often treated as an implementation detail.

The conversation sounds simple:

Should we use PostgreSQL or MongoDB?
Should we add Redis?
Which database scales better?

Six months later.

The product gains traction. Traffic hits 2,000 requests per minute. Suddenly, P99 latency spikes to 4 seconds. Your connection pool exhausts every time a scheduled reporting job runs. A single JOIN on a multi-million-row table locks up CPU cores, and your database memory charts skyrocket toward a production crash.

In a panic, the team throws a Redis cluster in front of the database to “cache the slow queries.” When that doesn’t fix the underlying write locks, someone suggests migrating to MongoDB because “Document stores scale better.”

This is the exact moment you realize a painful truth: You didn’t just pick a place to store data. You made an architectural decision that defined your system’s throughput limits, concurrency mechanics, scaling strategy and failure modes—and you did it without thinking.

A Relatable example

Consider a simple e-commerce application.

A customer places an order. The application needs to create the order, record its items, reserve inventory, and initiate payment.

Now ask a few questions:

What happens if the order is created but inventory reservation fails?
How do you prevent two customers from purchasing the last available item?
What happens when the product catalogue grows from 1,000 products to 10 million?
How efficiently can you retrieve an order with its items, payment status, and delivery information?
What happens when a query that worked perfectly in development becomes one of your most expensive production operations?

These are not just database questions. They are architectural questions.

And the database you choose determines which of them are straightforward, which require additional engineering, and which become significantly harder to get right.

Let’s look at why.

1. Your Data Model Is Also a Design Decision

One of the first mistakes developers make is choosing a database based on how the data looks rather than how the application needs to use it.

Imagine a product in an e-commerce application:

At first glance, this looks like a simple document. You could store it in a relational database or a document database.

Both can represent it.

But the important question isn’t whether a database can store your data.

It’s how the data relates to everything else in your system.

A product belongs to a category. An order contains products. A customer places orders. A payment belongs to an order. Inventory changes as orders are placed and cancelled.

The data is connected, and those connections carry business meaning.

In a relational database, you might model the relationships explicitly:

This structure makes several decisions explicit.

Products reference categories. Order items reference products. Prices and quantities have defined types. Foreign keys can prevent references to non-existent records.

The schema becomes part of the system’s correctness model.

A document database can also represent these relationships, but the design might look different. You may embed data that is usually retrieved together, reference data that changes independently, or maintain denormalized copies for specific queries.

Neither approach is automatically superior.

The difference is where you place the complexity.

With relational modeling, you often manage relationships through joins, constraints, and transactions. With document-oriented modeling, you may simplify particular reads but take on duplication, update coordination, or additional application logic.

The architectural question here is not which database can represent your data. It’s which data model best supports the relationships and operations your application must guarantee.

2. Start With Access Patterns, Not Database Popularity

Suppose you’re building a SaaS application.

You know you need to store users, projects, tasks, and activity logs.

That tells you what data exists. It doesn’t tell you how the system will access it.

Consider these operations:

Retrieve a project and its most recent tasks.
Find all tasks assigned to a user across multiple projects.
Display the latest 50 activity events for a workspace.
Calculate monthly usage for billing.
Search projects by name within a particular organization.

These queries have different requirements.

Some filter by relationships. Others sort by time. Some need aggregations. Others require low-latency lookups.

Your database schema, indexes, and even your choice of storage model should reflect these access patterns.

For example, if your application frequently retrieves recent activity for a workspace, you might query PostgreSQL like this:

A suitable index could be:

Why this index?
Because the query filters by workspace_id, sorts by created_at, and returns only a limited number of rows.

The index can help PostgreSQL locate the relevant workspace records and retrieve recent entries without sorting the entire matching dataset.

The exact benefit depends on the table size, data distribution, query plan, and workload. An index is not a guarantee of a faster query in every situation.

It also introduces costs: additional storage and work during inserts, updates, and deletes.

That is the trade-off.

Now imagine discovering this access pattern after the application is already in production. You may need to change indexes, restructure queries, or redesign the way activity data is stored.

None of that is impossible. But understanding the workload earlier can prevent avoidable complexity.

This is why database design should begin with questions like:

What are the most frequent reads and writes?
Which fields are used for filtering and sorting?
Which relationships must be traversed?
Which queries must remain fast as the dataset grows?
Which operations require aggregation or reporting?
What latency can the application tolerate?

Don’t choose a database because it fits your data. Choose a database architecture that fits the way your system uses that data.

3. Transactions Are Where Database Choices Become Business Decisions

Some operations can tolerate partial completion.

Others cannot.

If a user updates their profile picture and the notification email fails, the system can usually retry the email independently.

But if an order is recorded while its inventory reservation fails, the application may accept a purchase it cannot fulfil.

Consider this simplified NestJS service using Prisma:

The intention is sound: group the inventory update and order creation into one transaction so that a failure rolls back the database changes.

But there is a subtle concurrency problem.

Imagine the product has one item remaining.

Two requests arrive at almost the same time. Both read a stock value of one. Both pass the check. Both decrement the stock.

Depending on the database’s isolation behaviour and the operations performed, a naive read-check-update sequence can allow overselling or produce an invalid stock value.

Wrapping code in a transaction does not automatically make every business invariant safe.

One way to improve this design in PostgreSQL is to perform a conditional update:

The update only succeeds if sufficient stock remains when PostgreSQL evaluates the condition. Concurrent updates to the same row are coordinated by the database, and the predicate is checked against the row being updated.

If the update count is zero, the reservation failed. Throwing an error rolls back the transaction, including any order creation performed within it.

In a real system, you’d also validate that quantity is positive, enforce appropriate database constraints, and handle errors deliberately.

The important distinction is that the database is doing more than persisting information. It is helping enforce a business invariant under concurrency.

This is where database capabilities matter.

You need to understand:

Atomicity: do related database changes succeed or fail together?
Isolation: what can concurrent transactions observe?
Constraints: which invalid states can the database reject?
Locking: how are conflicting writes coordinated?
Durability: what guarantees exist after a successful commit?

A database that supports transactions, constraints, and suitable concurrency controls can make these guarantees easier to implement.

Other storage systems may offer different transaction scopes or consistency guarantees. Some can support the same business requirements, but the design and operational trade-offs may differ.

If your application depends on financial correctness, inventory accuracy, or reliable state transitions, transaction semantics are not a minor implementation detail. They’re part of your architecture.

4. Your Database Choice Changes How You Scale

“Will it scale?” is one of the most common questions developers ask about a database.

But scale is not a single problem.

A system may struggle because of:

Too many concurrent connections.
Expensive joins or poorly designed queries.
Missing or ineffective indexes.
Large write volumes.
Contention on frequently updated rows.
Growing storage requirements.
Read traffic that exceeds the primary database’s capacity.
Reporting workloads competing with transactional operations.

Different problems require different solutions.

Let’s say your SaaS application starts with a few hundred users and eventually serves tens of thousands.

Your first instinct might be to migrate to a distributed database.

But what if the actual problem is an unindexed query that scans millions of activity records?

What if your ORM is generating dozens of queries per request?

What if your application opens too many database connections?

Changing database engines may introduce more complexity without addressing the bottleneck.

A more sensible progression is to measure the workload, inspect query plans, improve access patterns, and identify the actual constraint.

Depending on the evidence, you might introduce:

Better indexes and query optimization.
Connection pooling.
Caching for frequently accessed data.
Read replicas for appropriate read-heavy workloads.
Partitioning for large tables with suitable access patterns.
Background processing for expensive non-interactive work.
Sharding or a different storage architecture when simpler options are insufficient.

Each option introduces trade-offs.

A read replica can distribute reads, but replication lag may mean a user doesn’t immediately see a recent write when reading from the replica.

Caching can reduce database load, but it introduces invalidation and freshness problems.

Partitioning can improve certain large-table workloads, but it requires careful key selection and query design.

Sharding can distribute data and load, but cross-shard queries, transactions, rebalancing, and operational complexity become harder.

The right decision depends on the bottleneck you’re solving.

This is also why the database choice matters early: it shapes the available optimization paths, the complexity of future changes, and the skills your team needs to operate the system.

However, your first database decision does not need to predict every future scaling problem.

It needs to support the current workload well without making reasonable future evolution unnecessarily difficult.

5. SQL vs. NoSQL Is the Wrong First Question

The SQL-versus-NoSQL debate often starts with the wrong assumption: that one category is inherently better for modern applications.

Relational databases are not outdated because document databases exist. Document databases are not automatically more scalable because their schemas are flexible.

These systems optimize for different requirements, and their capabilities overlap more than simplistic comparisons suggest.

A relational database such as PostgreSQL is often a strong starting point when your application has interconnected entities, important integrity constraints, complex queries, and transactional workflows.

A document database can be a good fit when your data is naturally document-oriented, access patterns align with document boundaries, and flexible document structures provide a practical advantage.

Key-value stores are useful when the workload primarily involves simple lookups by key and the chosen system provides the required durability and consistency guarantees.

Search engines are designed for sophisticated text retrieval, relevance scoring, and search-oriented indexing.

Time-series systems may be appropriate for workloads involving large volumes of timestamped measurements and time-based analysis.

Notice the pattern: each choice follows the workload and its requirements.

Even these categories are not mutually exclusive. PostgreSQL supports JSONB for semi-structured data, for example, and Redis supports more than basic key-value operations.

You don’t have to adopt a separate database for every data type or feature.

In fact, introducing several databases too early can create more problems than it solves.

Now your team has multiple systems to deploy, monitor, secure, back up, restore, and understand. Data may need to move between them, and cross-system consistency can become an application-level responsibility.

Polyglot persistence — using different storage technologies for different workloads — is a legitimate architectural strategy. But it should solve a concrete problem, not serve as a demonstration of technical sophistication.

For many applications, a well-designed PostgreSQL database is sufficient for transactional data, JSON-based fields, and a substantial range of query requirements.

Start with the simplest architecture that satisfies the requirements. Add another database when you can explain exactly what it provides that your existing system cannot provide efficiently or safely.

6. Operational Complexity Is Part of the Decision

A database is not just an engine you connect to using a connection string.

It is a system you must operate.

Before choosing one, consider what happens when things go wrong.

How are backups taken?
Have restores been tested?
How will schema migrations be deployed?
How will connection limits be managed?
How will slow queries be identified?
What happens during failover?
Can the team diagnose replication lag or storage pressure?

These questions are easy to ignore when an application is small.

They become important when the application holds customer data, processes payments, or supports a business that cannot afford extended downtime.

Consider connection pooling.

If your application runs multiple NestJS instances, each creating many database connections, the combined number of connections can overwhelm the database even when query volume is reasonable.

Adding more application instances may actually make the situation worse.

Similarly, a migration that works on a small development database may lock a large production table or take longer than the deployment window allows.

Operational requirements should therefore influence your choice.

A managed PostgreSQL service might be preferable to operating a more exotic database yourself. A specialized system may offer worthwhile benefits, but those benefits must justify the extra operational burden.

Evaluate the whole cost:

Infrastructure and storage.
Query performance under realistic workloads.
Backups and recovery.
Monitoring and debugging.
Deployment and migration safety.
Team familiarity and hiring.
Failure recovery and availability requirements.

The cheapest database to start with is not always the cheapest system to maintain.

And the most powerful database is not necessarily the best one for a team that lacks the experience to operate it reliably.

7. How to Choose a Database Without Guessing

You don’t need to predict every requirement your application will ever have.

You need a repeatable way to make the decision.

Here’s a practical framework.

Step 1: Identify the data and its relationships.

List the main entities, how they relate, and which invariants must always hold. Do customers own orders? Can an order exist without its items? Must every payment reference a valid order?

Step 2: List the important access patterns.

Write down the queries the application will execute most frequently. Include filtering, sorting, joins, aggregation, search, and write operations.

Step 3: Define consistency requirements.

Determine which operations must be atomic, which data can be eventually consistent, and what happens if a read returns a slightly stale result.

Step 4: Estimate the workload.

Think about expected read/write volume, concurrency, data growth, latency targets, and traffic patterns. Estimates do not need to be perfect, but assumptions should be explicit.

Step 5: Evaluate operational constraints.

Consider hosting, backups, recovery objectives, monitoring, migrations, connection management, budget, and your team’s experience.

Step 6: Test the risky parts.

Build a small proof of concept around the most demanding queries and transactions. Use realistic data volumes, inspect execution plans, and test concurrent operations.

Step 7: Record the trade-off.

Document why you chose the database, what assumptions the choice depends on, and what evidence would justify revisiting it.

A decision is much easier to evaluate when the reasoning behind it is visible.

A practical starting point

These are starting points, not universal prescriptions. Workload, consistency requirements, managed-service capabilities, and operational constraints can change the answer.

8. The Best Database Decision Is the One You Can Explain

A good engineer does not choose PostgreSQL because PostgreSQL is popular.

They choose it because its relational model, transactional capabilities, indexing, query flexibility, ecosystem, and operational characteristics fit the system’s requirements.

They don’t choose MongoDB merely because the schema changes frequently. They ask whether the data is naturally document-oriented, whether the access patterns fit the model, and how relationships and consistency should work.

They don’t introduce Redis simply because a request is slow. They first determine whether the database is actually the bottleneck and whether caching is appropriate for the freshness requirements.

The difference is not the technology.

It’s the reasoning behind the choice.

A database decision should be based on what the system needs to guarantee, how it needs to access its data, what workload it must support, and what complexity the team is prepared to own.

You may eventually replace the database. Requirements change, workloads grow, and new constraints emerge.

But you should not have to replace it because the original decision was based entirely on convenience or hype.

9. When to Revisit Your Database Decision

You don’t need to pick the “perfect” database on day one. But you do need to know when your current choice is becoming an architectural bottleneck.

Signals it’s time to rethink:

You’re adding more caches than features.
Your migrations regularly take hours or require maintenance windows.
You can’t explain your consistency model in one sentence.
Your team is afraid to touch certain tables.
You’re building custom sharding logic in your application.

At that point, you’re not “tweaking” your database. You’re redesigning your architecture.

Final Thoughts

It’s easy to choose a database when all you’re thinking about is getting your application to work.

The harder question is whether that choice will still make sense when your application has more data, more users, more complex business rules, and less room for failure.

That’s when the real consequences begin to surface.

The schema that once felt simple starts resisting new requirements. Queries that worked well at first become expensive. Concurrent requests expose inconsistencies you never anticipated. And the database you chose in a few minutes starts influencing decisions that take weeks to change.

None of this means you need to predict every future problem or choose the most sophisticated database available. You don’t.

What you need is a clear understanding of your application’s data, access patterns, consistency requirements, and operational constraints.

Sometimes, that understanding will lead you to PostgreSQL. Sometimes, a document database or a specialized storage system will make more sense. And sometimes, the best decision is to stick with what you already have and fix the actual problem.

The difference is that you’re no longer choosing based on hype, familiarity, or what everyone else seems to be using. You’re choosing based on what your system needs.

Good backend engineering isn’t about choosing the most powerful technology. It’s about making decisions whose trade-offs you understand and can justify.

Your database is one of those decisions.

Choose it deliberately.

Coupling vs. Cohesion: The Two Forces That Shape Good Software

Nsikan Patrick Adaowo — Thu, 17 Sep 2026 04:31:45 +0000

Good software is not only about making each component work.

It is also about deciding:

What belongs together?
What should stay separate?
Which modules should know about each other?
How much knowledge should one component have about another?
What should happen when one part of the system changes?

Two concepts help answer these questions:

Cohesion: how closely related the responsibilities inside a module are.

Coupling: how dependent one module is on other modules.

The goal is usually simple:

High cohesion within modules and low coupling between modules.

This sounds like a theoretical software engineering principle, but it directly affects how easy your system is to understand, test, scale, and change.

It works, but is that enough?

When developers build a feature under pressure, the first goal is usually to make it work.

That is understandable.

A client needs the feature. A product manager wants the release. A deadline is approaching. You write the endpoint, connect the database, call the external provider, return the response, and move on.

At that moment, the code may look perfectly fine.

The trouble starts when the system grows.

A simple order service begins to:

Validate customer information.
Calculate prices.
Apply discounts.
Check inventory.
Process payment.
Send emails.
Publish events.
Write audit logs.
Generate invoices.

A small change to the payment provider now requires opening the order service. A change to email behaviour affects order creation. A new discount rule breaks an unrelated checkout flow.
The code still works—but it has become expensive to change.

This is often a design problem involving coupling and cohesion.

What is cohesion?

Cohesion describes how closely related the responsibilities inside a module are.

A highly cohesive module focuses on one clear purpose.

For example, an authentication module may contain:

Login.
Logout.
Token refresh.
Password reset.
Session validation.

These responsibilities are related because they all belong to identity and access management.

A module that contains authentication, invoice generation, image resizing, and product recommendations has low cohesion.

The code may still compile, but the module does not have a clear identity.

A simple analogy
Imagine a toolbox.

A toolbox containing screwdrivers, pliers, measuring tape, and a wrench has a clear purpose: helping you perform repairs.

Now imagine opening the same toolbox and finding:

Cooking utensils.
Medical supplies.
Office stationery.
Car keys.
Gardening tools.

The box may contain useful things, but it is no longer organized around one meaningful purpose.

Low-cohesion software feels the same way.

You find unrelated functionality in the same class or module, and you are never sure where the next responsibility should go.

High cohesion in code
Consider this service:

The name UserService does not explain the actual boundaries.

Some methods deal with users. Others deal with communication, billing, and reporting.

A more cohesive design might separate them:

Now each module has a clearer purpose.

When a developer needs to change password-reset behavior, they know where to look.

When invoice requirements change, authentication code is less likely to be affected.

That is the practical benefit of cohesion: related things stay together, and unrelated things stay apart.

What is coupling?

Coupling describes the degree of dependency between different modules.

Two modules are tightly coupled when one knows too much about the other or depends heavily on its internal details.

A change in one module may force changes in several others.

Consider:

This service is coupled to:

Paystack.
Prisma.
A specific payment response format.
A specific database implementation.

If you replace Paystack, change the database library, or alter the payment workflow, this service must change.

That is tight coupling.

A loosely coupled design depends on stable contracts instead:

The order service depends on capabilities, not concrete infrastructure:

Now the payment provider and database implementation can change behind the abstractions.

Cohesion and coupling work together

Cohesion and coupling are not competing goals.

They describe two sides of software structure:

Cohesion looks inside a module.
Coupling looks between modules.

A healthy design aims for:

High cohesion inside
Low coupling between

Think of a well-organized company.

Each department focuses on a specific responsibility:

Finance handles finances.
Human resources handles people operations.
Sales handles customers and revenue.
Engineering handles product development.

The departments still communicate, but they do so through clear responsibilities and defined processes.

If every department performs every task, the organization becomes chaotic.

If departments cannot communicate at all, work also stops.

Software modules behave similarly.

The goal is not zero coupling.

The goal is controlled coupling.

Why zero coupling is impossible

Every useful system contains dependencies.

An order system needs payment information. A dashboard needs reporting data. A notification service needs information about events. A controller needs an application service.

The goal is not to remove every dependency.

The goal is to make dependencies:

Necessary.
Explicit.
Stable.
Small.
Easy to replace.
Easy to test.
Easy to understand.

A controller depending on an application service is normal.

An application service knowing the private implementation details of three databases, two payment providers, and an email server is a warning sign.

Types of coupling

Coupling can appear in different forms.

Content coupling
One module directly accesses or modifies the internal data of another module.

This is highly dangerous because the consuming module depends on implementation details.

If internalState changes, the order service breaks.

Common coupling
Multiple modules depend on shared global state.

Global state can make behavior difficult to predict and test.

One module may modify the state while another module assumes it has not changed.

Control coupling
One module tells another how to behave by passing flags.

This can become problematic when the receiving service accumulates many branches:

Sometimes a strategy or channel abstraction is clearer.

Data coupling
One module passes only the data another module needs.

This is generally healthier because the dependency is explicit and limited.

Message coupling
Modules communicate through messages or events without depending heavily on each other’s internal structure.

Message-based communication can reduce direct coupling, though it introduces other concerns such as event versioning, delivery guarantees, retries, and eventual consistency.

Types of cohesion

Cohesion can also vary in strength.

Functional cohesion
A module contains elements that work together to perform one well-defined task.

Example:

Both methods belong to password hashing.

Sequential cohesion
One operation produces data consumed by another operation within the same module.

For example:

These operations form a clear sequence in a file-import workflow.

Communicational cohesion
Several operations work on the same data.

For example, a profile module may validate, update, and format user-profile data.

Coincidental cohesion
A module contains unrelated utilities simply because they were created around the same time.

This kind of module often grows into a dumping ground.

The problem with utility folders is not that utilities are always bad. The problem is that unrelated behaviour becomes difficult to own, test, and discover.

A practical example: order processing
Let us compare two designs.

Low cohesion and high coupling

This service has many responsibilities.

It is also coupled to several infrastructure systems.

Possible consequences:

Large and slow tests.
Difficult mocking.
High risk of regression.
Unclear error handling.
Difficult reuse.

Every change affects the same class.

High cohesion and controlled coupling

Each component owns a focused responsibility.

The use case still coordinates the workflow, but the details are distributed across meaningful boundaries.

This design is not automatically perfect.

It may introduce more files and abstractions.

But if the application is complex and these concerns change independently, the separation creates value.

Coupling in a NestJS application

NestJS encourages dependency injection, which can help reduce coupling.

A service can receive dependencies through its constructor:

This is better than constructing concrete dependencies inside the service:

Constructor injection makes dependencies visible.

It also makes testing easier:

The service can be tested without connecting to a real database or sending real emails.

However, dependency injection alone does not guarantee low coupling.

You can still inject a massive concrete service that exposes too many responsibilities.

The quality of the boundary matters more than the presence of the injection mechanism.

Coupling in modular monoliths

A modular monolith may run as one deployable application while maintaining strong internal boundaries.

For example:

The modules can communicate through:

Public application interfaces.
Domain events.
Commands.
Queries.
Shared contracts.

They should avoid reaching directly into one another’s internal repositories or private tables without a clear reason.

A modular monolith can provide many benefits of good boundaries without immediately introducing the operational complexity of microservices.

This is especially useful for early-stage SaaS products.

You can keep deployment simple while keeping responsibilities organized.

Coupling in microservices

Microservices do not automatically create low coupling.

A system can have separate deployable services and still be tightly coupled if:

Every request requires five synchronous service calls.
Services share the same database tables.
One service depends on another’s internal schema.
All services must deploy together.
A small contract change breaks many consumers.
A single service failure brings down the entire workflow.

This is distributed coupling.

The services are separate in code and deployment,but tightly connected in behaviour.

A well-designed microservice should own a meaningful capability and communicate through stable contracts.

But even then, network communication introduces costs:

Latency.
Timeouts.
Retries.
Partial failures.
Versioning.
Observability.
Eventual consistency.

Sometimes a well-modularized monolith has less harmful coupling than a poorly designed microservice architecture.

The number of services is not a measure of design quality.

Cohesion and database design

Coupling and cohesion also apply to data.

A module should ideally own the data required for its responsibility.

For example:

Billing module → subscriptions, invoices, billing transactions
Inventory module → stock levels, reservations, warehouses
Identity module → users, credentials, sessions, permissions

If every module directly reads and writes every table, the database becomes a hidden integration layer.

Changes become risky because nobody knows which services depend on which columns, indexes, or status values.

This does not mean every module must have a separate database.

A modular monolith can use one database while still enforcing ownership boundaries.

The important question is:

Who owns this data, and how should other modules access it?

Clear ownership improves cohesion.
Controlled access reduces coupling.

Coupling and event-driven design

Events can reduce direct dependency between modules.

Instead of the order module directly calling the notification module:

it may publish an event:

The notification module subscribes to that event.

This creates looser direct coupling because the order module does not need to know how notifications work.

However, event-driven systems introduce new trade-offs:

Events may be delayed.
Events may be delivered more than once.
Consumers may process events out of order.
Event schemas must evolve carefully.
Debugging requires tracing across asynchronous flows.
Data may become eventually consistent.

Events reduce some forms of coupling, but they do not eliminate system complexity.

They move the complexity from direct calls to contracts, delivery, and observability.

Signs of high coupling

Your codebase may be tightly coupled when:

A small change requires edits across many modules.
Tests need the entire application to run.
Classes instantiate their own dependencies.
Modules access one another’s private data.
A shared utility module contains business logic for everything.
Multiple services depend on the same database schema.
Replacing a provider requires changing business logic.
One failed dependency causes unrelated features to fail.
Developers avoid refactoring certain areas because the impact is unpredictable.

High coupling creates a change ripple.

One adjustment travels through the system, touching code that should not have been affected.

Signs of low cohesion

A module may have low cohesion when:

Its name is vague, such as CommonService or Utils.
Its methods serve unrelated business functions.
It changes frequently for different reasons.
Developers are unsure where to add new functionality.
The module has too many dependencies.
Its tests cover unrelated behaviour.
Removing one method leaves the remaining methods unrelated.
The module requires a long explanation before anyone understands its purpose.

A useful question is:

If I had to describe this module in one sentence, would the description be clear?

If the answer is no, the module may need a better boundary.

How to improve cohesion

Group behavior by business capability
Instead of organizing everything by technical type:

controllers/
services/
repositories/
utils/

consider also thinking in terms of capabilities:

The best structure depends on the application, but grouping related behavior makes ownership clearer.

Keep related data and behavior close
If a business rule always operates on a particular concept, consider keeping the rule near that concept.

For example, order status transitions may belong to an order domain model or order service rather than a general utility file.

Separate unrelated reasons to change
If one module changes because of payment requirements, email requirements, and reporting requirements, it probably contains multiple responsibilities.

Split it around those change patterns.

Avoid generic dumping grounds
Be cautious with:

utils.
helpers.
common.
misc.
shared-service.

These folders can be useful, but they often become places where code is stored without a clear owner.

How to reduce coupling

Depend on abstractions
Define contracts around capabilities:

The application service should not need to know the database library.

Use dependency injection
Pass dependencies into a component instead of constructing them internally.

This makes dependencies explicit and replaceable.

Encapsulate internal details
Expose what another module needs, not everything the module knows.

A module should not expose its internal database models, private state, and implementation-specific helper methods unnecessarily.

Prefer messages for some workflows
Events and commands can reduce direct knowledge between modules.

Use them where asynchronous behavior and eventual consistency are acceptable.

Define stable contracts
Use clear request and response models.

Avoid passing internal database entities everywhere. Internal data structures change more frequently than business contracts.

Limit shared mutable state
Shared mutable state is one of the easiest ways to create unpredictable coupling.

Prefer explicit inputs and outputs.

The balance: cohesion versus coupling

It is possible to overcorrect.

Suppose you split one simple function into ten classes.

You may reduce local responsibilities, but create excessive coordination and indirection.

This is sometimes called accidental complexity.

A good architecture balances:

Cohesion.
Coupling.
Simplicity.
Performance.
Team understanding.
Operational cost.

You do not want modules so large that everything is mixed together.

You also do not want modules so fragmented that understanding one workflow requires jumping through twenty files.

The right boundary is usually where:

Responsibilities change together.
Data is accessed together.
Business rules belong together.
The module can be explained clearly.
The dependency is meaningful.

A useful code review framework

When reviewing a module, ask:

About cohesion

Do these methods belong to the same business capability?
Do they use the same data?
Do they change for similar reasons?
Does the module have one clear purpose?

About coupling

What does this module know about other modules?
Does it depend on implementation details?
Can a dependency be replaced easily?
Does a small change here affect many consumers?
Are dependencies explicit?

About boundaries

Who owns this business rule?
Who owns this data?
Is this communication synchronous or asynchronous?
Is the contract stable?
Is the abstraction solving a real problem?

These questions help you evaluate design beyond whether the code is syntactically clean.

The connection to SOLID

Coupling and cohesion are closely connected to SOLID principles.

Single Responsibility improves cohesion.
Open/Closed reduces unnecessary changes to stable modules.
Liskov Substitution creates reliable contracts.
Interface Segregation reduces unnecessary dependencies.
Dependency Inversion reduces coupling to infrastructure.

They are also related to:

Encapsulation.
Separation of concerns.
Domain-driven design.
Modular architecture.
Clean architecture.
Hexagonal architecture.
Event-driven design.

But the underlying idea remains simple:

Put related responsibilities together, and prevent unrelated components from knowing too much about one another.

Final thoughts

Good software is not made of isolated components that never communicate.

It is made of focused components that communicate intentionally.

High cohesion gives each module a clear identity.

Low coupling prevents changes from spreading unnecessarily.

When cohesion is low, modules become confusing.

When coupling is high, the entire system becomes fragile.

When both are poor, every feature becomes a negotiation with the existing codebase.

The goal is not to eliminate dependencies.

The goal is to make dependencies deliberate, visible, and manageable.

So, the next time you create a service, module, class, or microservice, ask two questions:

Does everything inside this component belong together?

And:

Does this component know more about the outside world than it needs to know?

Those two questions can prevent a lot of future pain.

Because maintainable software is not software with no complexity.

It is software where complexity has been given a clear place to live.

When Abstraction Becomes a Bottleneck: The Real Cost of Overengineering

Nsikan Patrick Adaowo — Thu, 10 Sep 2026 14:04:08 +0000

Abstraction is one of the most powerful tools in software engineering.

It hides complexity. It reveals intent. It reduces duplication. It makes systems easier to understand, test, and change.
But abstraction has a shadow side.

When applied too early, too generically, or without a clear problem, abstraction can become a bottleneck.

It can make code harder to read, harder to debug, and harder to evolve.

It can turn simple workflows into mazes of indirection.

It can create the illusion of flexibility while introducing hidden coupling.

And perhaps most dangerously, it can make engineers feel productive while actually reducing the team’s ability to ship.

This article explores when abstraction becomes harmful, why overengineering is more expensive than duplication, and how to recognize the signs that your design is working against you.

The promise of abstraction

Abstraction is how we manage complexity.

Instead of thinking in terms of bits and bytes, we work with concepts like users, orders, payments, and notifications.

Instead of repeating the same logic in ten places, we extract a function.

Instead of coupling business rules to a specific database, we define a repository interface.

Good abstractions:

Reduce cognitive load.
Clarify intent.
Make change safer.
Enable reuse.
Protect core logic from infrastructure details.

They are essential for building maintainable systems.

But not every abstraction is good.

And not every problem needs an abstraction.

The hidden cost of premature abstraction

Premature abstraction happens when you generalize a solution before you fully understand the problem.

You see a pattern that appears twice. You assume it will appear a third time. You create an interface, a factory, a strategy, and a configuration object to support every possible future variation.

The code looks sophisticated.

But the abstraction is built on assumptions, not evidence.

The asymmetry of technical debt

There is an important asymmetry between premature optimization and premature abstraction.

Premature optimization usually affects a localized part of the code.

For example, you implement a complex caching layer for a function that is called a few times per day. The optimization is unnecessary, but its impact is limited.

Premature abstraction, on the other hand, can affect the entire architecture.

When you introduce semantic boundaries and logical coupling before the problem domain is understood, you create a mesh of dependencies that resists evolution.

The cost of unwinding a wrong abstraction is not linear.

It is often geometric.

You may need to dismantle entire subsystems, update multiple layers, and reconcile conflicting mental models.

The cost of removing a premature optimization is typically isolated to a specific function or block.

The cost of removing a premature abstraction can ripple through the entire codebase.

Signs that abstraction has become a bottleneck

1. Too many layers of indirection
You need to jump through five files to understand a simple operation.

Controller → Service → UseCase → Handler → Processor → Adapter

Each layer adds indirection without adding clarity.

The call chain is deep, but the business intent is unclear.

2. Overly complex class hierarchies
Your class hierarchy has multiple levels of abstract classes and interfaces.

BaseService → AbstractCrudService → EntityService → UserService

Each layer introduces hooks, configuration options, and extension points that are rarely used.

New developers cannot tell which methods are important and which are legacy.

3. Methods with too many parameters
A method signature looks like this:

The method tries to support every possible scenario.

As a result, it is difficult to call, difficult to test, and difficult to understand.

4. Generic components that handle everything
A single component or service tries to support every use case.

The class becomes a dumping ground for unrelated functionality.

Its name no longer communicates intent.

5. Configuration objects that hold everything
A configuration object accumulates settings for multiple concerns:

The configuration becomes unreadable and impossible to evolve safely.

Changing one setting may affect unrelated parts of the system.

6. Names that hide intent
Classes and functions are named with generic terms:

Manager
Processor
Handler
Service
Controller
Provider

The names do not convey what the component actually does.

A developer must read the implementation to understand its purpose.

7. Conditional branches that proliferate
A single function contains many conditional branches to support different scenarios:

The function tries to be versatile, but it becomes complex and fragile.

Adding a new type requires modifying the central function and understanding all existing branches.

8. Onboarding becomes extremely difficult
New developers take weeks to understand the codebase.

They must decipher multiple layers of abstraction before they can make a simple change.

The joy of building yields to the chore of deciphering.

9. Breaking one abstraction breaks the whole
A single abstraction is used by many parts of the system.

When you change it, multiple features break.

The abstraction has become a concentration risk.

10. Domain intent disappears
The code no longer reflects the business domain.

Instead of Order, Payment, and Invoice, you have Entity, Resource, and Model.

Instead of chargePayment, you have executeAction.

The connection between the code and the problem it solves is lost.

The real cost of overengineering

Overengineering is not just an aesthetic problem.

It has real costs.

- Slower development
Features take longer to implement because engineers must navigate multiple layers of abstraction.

Simple changes require understanding complex call chains.

Estimates slip because the cognitive surface is larger than it appears.

- More bugs
Abstractions that try to support too many scenarios introduce edge cases.

Conditional branches multiply.

Configuration options interact in unexpected ways.

The system becomes harder to reason about, and bugs become harder to locate.

- Higher maintenance cost
Maintaining an overengineered system requires more effort.

Developers must understand not only what the code does, but why it was designed this way.

Refactoring becomes risky because the impact of changes is difficult to predict.

- Reduced morale
Engineers join teams to build things.

When the codebase feels like a maze, motivation declines.

Talent departs when the joy of building yields to the chore of deciphering.

- Lost opportunities
Overengineered systems resist change.

New ideas are avoided because they do not fit the existing abstraction.

The team spends more time reconciling mental models than shipping value.

Duplication is cheaper than the wrong abstraction

One of the most important lessons in software design is this:

Duplication is far cheaper than the wrong abstraction.

When you duplicate code, you pay a localized cost.

When you change one copy, you may need to change the other.

But the impact is limited.

When you create the wrong abstraction, you pay a systemic cost.

The abstraction couples multiple parts of the system.

Changing it requires understanding all consumers.

The cost of unwinding it can be geometric.

This does not mean duplication is always good.

It means that premature generalization is often more expensive than waiting until the pattern is clear.

A useful rule is the “rule of three”:

Implement the logic the first time.

Implement it the second time, even if it looks similar.
When you see it a third time, consider an abstraction.

This rule is not absolute, but it encourages evidence-based design.

You abstract when you have seen the pattern, not when you predict it.

When abstraction is appropriate

Abstraction is not the enemy.

Bad abstraction is.

Good abstraction is appropriate when:

The pattern has appeared multiple times.
The variation is real, not speculative.
The abstraction clarifies intent.
The boundary is meaningful.
The cost of change is reduced.
The team can understand and maintain it.
For example, a payment gateway abstraction is useful when:
You have multiple payment providers.
The business may change providers.
The core logic should not depend on a specific provider.
Testing is easier with a fake implementation.
A repository abstraction is useful when:
The data access strategy may change.
The domain logic should not depend on a specific database.
Testing is easier with an in-memory implementation.

But if you have one payment provider and no plan to change, a direct implementation may be simpler.

If you have one database and no need for multiple implementations, a direct repository may be clearer.

The goal is not to avoid abstraction.

The goal is to avoid abstraction that does not yet earn its place.

The YAGNI principle

YAGNI stands for “You Aren’t Going to Need It.”

The principle says:

Do not implement functionality until it is necessary.

This does not mean you should ignore the future.

It means you should not implement speculative features or abstractions based on assumptions.

There is no reason to make code more complicated just so that down the road you may be able to make it more flexible.

YAGNI complements other principles such as:

DRY (Don’t Repeat Yourself).
KISS (Keep It Simple, Stupid).
SOLID.
Separation of concerns.

The balance is important.

DRY encourages removing duplication.

YAGNI encourages waiting until the duplication is real.

Together, they suggest:

Do not repeat yourself unnecessarily, but do not abstract prematurely.

WET before DRY
Another useful perspective is “WET before DRY.”

WET stands for “Write Everything Twice.”

The idea is that duplicating code once or twice is not costly.

It allows you to understand the pattern before abstracting it.

Starting with DRY from the beginning increases the chances of bad generalizations.

When you attempt to DRY up the code too early, you may:

Optimize prematurely.

Bundle operations with different contexts.

Create abstractions that do not fit the problem.

An alternative is to see WET and DRY as complementary.

Start with a basic design.

When you find duplicated code two or three times, consider an abstraction.

After working on the problem for some time, reflect on how to abstract based on the challenges you faced.

Practical guidelines for avoiding over-abstraction

1. Wait for evidence
Do not abstract based on predictions.

Wait until you have seen the pattern multiple times.

Ask:

Has this variation appeared in production?

Is this a real requirement or a hypothetical scenario?

Will this abstraction simplify the next feature?

2. Favor explicit code
Explicit code is easier to understand than clever abstractions.

If a function has three clear steps, write them explicitly.

If a workflow has four distinct operations, name them clearly.

Do not hide simple logic behind layers of indirection.

3. Keep abstractions close to the domain
Abstractions should reflect the business domain, not technical convenience.

Use names like Order, Payment, and Invoice instead of Entity, Resource, and Model.

Use verbs like chargePayment and createOrder instead of executeAction and processResource.

4. Limit configuration
Avoid configuration objects that hold everything.

Split configuration by concern:

Database configuration.
Feature flags.
External API keys.
Tenant settings.

This makes the configuration easier to understand and evolve.

5. Reduce indirection
Ask whether each layer adds value.

If a layer only delegates to another layer without adding behaviour, consider removing it.

Deep call chains increase cognitive load without improving design.

6. Test the abstraction
Before adopting an abstraction, ask:

Can a new developer understand it in ten minutes?
Does it make the next feature easier to implement?
Does it reduce the number of concepts a developer must hold in their head?
Does it make testing easier or harder?

If the answer is no, the abstraction may not be worth the cost.

7. Prefer composition over inheritance
Inheritance can create deep hierarchies that are difficult to understand.

Composition allows you to assemble behaviour from smaller components.

For example:

This is often clearer than a deep inheritance tree.

8. Document the intent
If an abstraction is necessary, document its intent.

Explain:

Why the abstraction exists.
What problem it solves.
What scenarios it supports.
What scenarios it does not support.

This helps future developers understand the design decisions.

A practical example: notification service
Consider a notification system.

Overengineered design

The abstraction tries to support every possible scenario.

The configuration object holds settings for multiple concerns.

The method contains many conditional branches.

Adding a new channel requires modifying the central method and understanding all existing logic.

Simpler design

Each channel is a separate implementation.

The service delegates to the appropriate channel.

Adding a new channel requires creating a new implementation, not modifying existing logic.

The design is simpler, clearer, and easier to extend.

When to refactor

Refactoring is appropriate when:

The pattern has appeared multiple times.
The duplication is causing maintenance problems.
The abstraction will clarify intent.
The team can understand and maintain it.
The cost of change is reduced.
Refactoring is premature when:
The pattern has appeared once.
The variation is speculative.
The abstraction adds indirection without clarity.
The team cannot explain the design in simple terms.
The cost of change increases. The goal is not to avoid refactoring.

The goal is to refactor based on evidence, not prediction.

The balance: Goldilocks abstraction

Abstraction should be “just right.”

Not too little, not too much.

A codebase with too little abstraction can be repetitive and difficult to maintain.

A codebase with too much abstraction can be difficult to understand and evolve.

The sweet spot is when:

The code reflects the domain.
The abstractions are meaningful.
The call chains are shallow.
The intent is clear.
The team can onboard quickly.
Change is easier, not harder.
This balance is not static.
It evolves as the system grows and the team learns.

The important skill is recognizing when an abstraction has crossed the line from helpful to harmful.

Final thoughts

Abstraction is a tool, not a goal.

Good abstraction reduces complexity.

Bad abstraction creates it.

The real cost of overengineering is not measured in lines of code.

It is measured in:

Slower development.
More bugs.
Higher maintenance cost.
Reduced morale.
Lost opportunities.

Duplication is often cheaper than the wrong abstraction.

Waiting for evidence is often wiser than predicting the future.

Explicit code is often clearer than clever design.

The next time you create an abstraction, ask:

Does this simplify the next feature?
Can a new developer understand this in ten minutes?
Is this pattern real or speculative?
Does this reduce or increase the cognitive load?

Because good software is not software with the most abstractions.

It is software that can be understood, changed, and extended without unnecessary friction.

And sometimes, the best design is the one that resists the urge to generalize before it is ready.

Dependency Injection Explained: Why Your Classes Shouldn't Know How Everything Is Built

Nsikan Patrick Adaowo — Sun, 30 Aug 2026 12:31:31 +0000

Your codebase may not be failing because it lacks features. It may be failing because everything knows too much about everything else.

Most backend developers learn dependency injection through a framework.

In NestJS, you add decorators. In Spring, you annotate classes. In Angular, you declare providers. The framework then constructs your objects and passes their dependencies.

Everything works fine.

But many developers stop at the mechanics.

They learn how to use dependency injection, but not why it matters.

They learn the syntax, but not the design principle.

They learn the pattern, but not the problem it solves.

The result is code that uses dependency injection but still feels tightly coupled, difficult to test, and fragile when requirements change.

This article explains what dependency injection really is, why your classes should not know how their dependencies are built, and how to use it in a way that improves maintainability, testability, and flexibility.

The problem: classes that build their own world

Consider this service:

This code may work.

But it has a hidden problem.

The OrderService knows:

Which database library to use.
Which payment provider to call.
Which email client to instantiate.
How to construct each dependency.

This creates tight coupling.

If you want to:

Replace Paystack with Flutterwave.
Switch from Prisma to TypeORM.
Use a different email provider.
Test the service without calling real APIs.
Use a different configuration in staging versus production.

you must modify the service itself.
The class is responsible not only for its business logic, but also for constructing its entire world.
This is the opposite of what dependency injection tries to achieve.

What dependency injection actually is

Dependency injection is a design pattern where a class receives its dependencies from the outside instead of creating them internally.
Instead of:

You write:

The dependency is provided by an external assembler, such as:

A framework container.
A factory function.
A manual composition root.
A dependency injection library.

The class no longer decides how its dependencies are built.
It only declares what it needs.

Inversion of Control: the bigger idea

Dependency injection is a specific way to implement a broader principle called Inversion of Control.
In traditional code, a high-level component directly creates or locates its low-level dependencies.
For example:

The ReportGenerator controls how the database is obtained.
Under Inversion of Control, this responsibility is inverted.
An external mechanism provides the dependency:

Now the framework or container controls object creation and dependency resolution.
The high-level component declares what it needs but does not control how it is constructed.
This inversion of control leads to looser coupling and greater flexibility.

Constructor injection: the most common form

The most widely used form of dependency injection is constructor injection.
Dependencies are passed through the constructor:

This approach has several advantages:

The object is fully initialized when created.
Dependencies are clearly visible in the constructor signature.
Fields can be immutable.
It fails fast if a dependency is missing.

A class that requires certain dependencies should not be constructible without them.
Constructor injection enforces this requirement.

Setter and interface injection

Other forms of dependency injection exist, though they are less common in modern backend code.

Setter injection

Dependencies are provided through setter methods after construction:

This can be useful when dependencies are optional or change over time, but it also allows objects to exist in a partially initialized state.

Interface injection

A class implements an interface that defines how dependencies are injected.
This is less common in TypeScript and JavaScript ecosystems.
For most backend applications, constructor injection is the simplest and most reliable approach.

A practical NestJS example

NestJS provides a built-in dependency injection container.
A service can declare its dependencies in the constructor:
NestJS resolves the dependencies when the service is instantiated.
The service does not need to know:

Whether OrderRepository uses Prisma, TypeORM, or a raw SQL client.
Whether PaymentGateway is implemented with Paystack, Stripe, or a mock.
How NotificationService sends messages.

It only knows the capabilities it requires.
This separation makes the service easier to test and easier to evolve.

Why dependency injection matters

1. Reduced coupling
When a class constructs its own dependencies, it is tightly coupled to those implementations.
Dependency injection separates the use of a dependency from its construction.
The class depends on an abstraction or interface, not on a specific concrete class.
This makes it easier to switch implementations without modifying the consumer.
For example, you can replace a payment gateway implementation without changing the order service.
2. Improved testability
Testing becomes easier when dependencies can be replaced with fakes or mocks.
Consider this test:

The test can verify:

The correct amount is charged.
The order is created with the right data.
The notification is sent.
Error handling behaves correctly.

No real database, payment provider, or email server is required.
This makes tests faster, more reliable, and easier to run in isolation.
3. Easier configuration management
Different environments often require different configurations.
For example:

Development may use local services.
Staging may use test providers.
Production may use real providers.

With dependency injection, you can compose different implementations for different environments without changing the core business logic.
4. Clearer responsibilities
When a class receives its dependencies, its constructor signature communicates what it needs.
This makes the code easier to understand.
A developer can look at the constructor and immediately see the external capabilities the class depends on.
This is more explicit than hidden instantiations scattered throughout methods.
5. Better separation of concerns
Dependency injection helps separate:

Business logic.
Infrastructure details.
Object construction.
Configuration.

The business logic focuses on what needs to happen.
The infrastructure layer focuses on how to interact with external systems.
The composition root or container focuses on how to assemble everything.
This separation makes the system easier to reason about and easier to change.

Dependency injection versus service locator

A service locator is another pattern for obtaining dependencies.
Instead of injecting dependencies, a class asks a central registry for them:

This may look convenient, but it has important drawbacks:
Dependencies are hidden.

The class can request anything from the locator.
It is harder to see what a class truly needs.
Tests must configure the global locator.
It can encourage tight coupling to the locator itself.

Dependency injection makes dependencies explicit and visible in the constructor.
This clarity is one of its main advantages.

Common mistakes with dependency injection

Injecting concrete implementations everywhere

Dependency injection is most powerful when classes depend on abstractions.
If every service depends directly on concrete classes, you still have tight coupling, even if the container constructs them.
For example:

This is better than creating new PrismaClient() inside the service, but the service is still coupled to Prisma.
A repository abstraction can help:

Now the service depends on a capability, not a specific library.

Overusing dependency injection

Not every function needs to be a class with injected dependencies.
Simple utilities, pure functions, and small helpers may not benefit from dependency injection.
For example:

This function has no external dependencies.
Wrapping it in a class and injecting it through a container adds unnecessary complexity.
Use dependency injection where it solves a real problem: managing dependencies, improving testability, and reducing coupling.

Creating too many tiny services

Dependency injection can encourage splitting behavior into many small services.
This can be useful, but it can also create fragmentation.
If understanding one workflow requires jumping through twenty classes, the design may be over-engineered.
The goal is not maximum fragmentation.
The goal is clear responsibilities and manageable boundaries.

Ignoring the composition root

In a NestJS application, the framework handles much of the composition.
But in plain TypeScript or other environments, you need a place where the application is assembled.
This is often called the composition root.

It is where you:

Create concrete implementations.
Configure providers.
Wire dependencies together.
Start the application.

Keeping this logic centralized makes the system easier to understand and easier to configure for different environments.

Dependency injection and interfaces

Dependency injection works especially well with interfaces or abstract classes.
An interface defines a contract:

Multiple implementations can satisfy the contract:

The business logic depends on the interface:

This makes it easy to:

Switch providers.
Test with a fake implementation.
Introduce a new provider without modifying the checkout logic.

The class does not know how the payment is implemented.
It only knows what it can ask the payment gateway to do.

Dependency injection in a multi-tenant SaaS

In a multi-tenant SaaS platform, different tenants may require different configurations.
For example:

Different payment providers.
Different email providers.
Different storage backends.
Different feature flags.

Dependency injection can help you compose tenant-specific implementations.
A tenant context can determine which implementation to use:

The rest of the application depends on PaymentGateway, not on the specific provider.
This keeps tenant-specific logic contained and makes the core application more stable.

Dependency injection and testing strategies

Dependency injection enables several testing strategies.

Unit testing with fakes

You can provide simple in-memory or hardcoded implementations:

The service can be tested without a real database.

Unit testing with mocks

Mocking libraries can create objects that record how they were called:

This verifies that the service interacts correctly with its dependencies.
Integration testing with real dependencies
For integration tests, you can use real or containerized dependencies:

A test database.
A test message broker.
A test email service or stub.

Dependency injection makes it easier to swap between test and production configurations.

Dependency injection and clean architecture

Clean architecture and hexagonal architecture emphasize separating:

Domain logic.
Application logic.
Infrastructure.
Interfaces.

Dependency injection supports this separation by allowing inner layers to depend on abstractions while outer layers provide concrete implementations.
For example:

The application layer does not import infrastructure details.
It only defines the capabilities it needs.
This makes the system easier to evolve and easier to test.

When dependency injection may be overkill

Dependency injection is not required for every piece of code.
It is most valuable when:

A class has external dependencies.
You need to test the class in isolation.
Implementations may change.
Configuration differs between environments.
You want to reduce coupling.

It may be unnecessary when:

The code is a simple script.
The function has no external dependencies.
The behaviour is trivial and stable.
The overhead outweighs the benefit.

Use dependency injection intentionally, not as a default ritual.

A simple mental model

You can think of dependency injection as answering three questions:
What does this class need?
Declared in the constructor.
Who provides it?
The container, factory, or composition root.
How is it built?
The concrete implementation, configuration, or environment.
The class only answers the first question.
The other questions are handled externally.
This separation is what makes the code more flexible and easier to test.

Final thoughts

Dependency injection is not only a framework feature.
It is a design choice about who controls object creation and how dependencies are managed.
When your classes know how to build everything they need, they become tightly coupled to those implementations.
When your classes declare what they need and receive it from the outside, they become easier to test, easier to configure, and easier to change.
This does not mean every function must be a class with injected dependencies.
It means that when a component has external dependencies, those dependencies should be explicit, replaceable, and managed outside the component.
Because good software is not only about making each class work.
It is about designing a system where change does not require rewriting everything that depends on it.
And dependency injection is one of the most practical tools for achieving that.

What Actually Happens When 10,000 Users Hit Your "Buy Now" Button at The Same Time

Nsikan Patrick Adaowo — Mon, 03 Aug 2026 18:25:56 +0000

Every e-commerce team dreams of massive traffic spikes—until those spikes actually happen.

Imagine this: You’ve spent weeks (maybe months) building your e-commerce backend. Your API endpoints are clean, your database schema is normalized, and your authentication flow is solid. You test it with 10 users. It works. You test with 100. It still works.

Then Black Friday hits. Or your product goes viral on TikTok. Or a celebrity tweet about your app. Suddenly, it’s no longer just one request (or even a hundred)—it’s 10,000, all landing on the same endpoint within the same second, all fighting over the same rows in your database.

Your server slows to a crawl. Some users get errors. Others get charged twice. A lucky few get their orders, but the rest get nothing.

This is the exact moment most engineers discover that “it works on my machine” and “it works under concurrency” are two completely different claims.

What Went Wrong?

This isn’t just a “traffic spike” problem. It’s a concurrency, architecture, and systems design problem. If you’re building scalable backends—especially in Node.js, NestJS, or any modern stack—you need to understand exactly what happens under the hood when thousands of requests hit your API simultaneously.

The Mental Model: One Server, Thousands of Requests

Let’s start with a simple question: Does your server create 10,000 copies of itself when 10,000 users hit it at once?

No. It doesn’t.

What actually happens is far more interesting—and more fragile.

Your server has limited resources: CPU cores, memory, network bandwidth, and database connections. When a flood of requests arrives, your server doesn’t magically scale up. Instead, it tries to juggle those requests using the tools and patterns you’ve (hopefully) built into your architecture.

In Node.js, for example, there’s only one main JavaScript thread—but that doesn’t mean it handles requests one at a time. It handles them concurrently, not in parallel.

Concurrency vs. Parallelism: The Core Distinction

This is where most developers get tripped up.

- Concurrency means multiple requests are in progress at the same time but not necessarily executing at the same time.

- Parallelism means multiple requests are actually executing at the same time, on different CPU cores or threads.

A common misconception about Node.js is that because it is single-threaded, high traffic will cause requests to pile up like cars stuck at a single toll booth.

In reality, Node.js is single-threaded but highly concurrent. It uses an event loop to delegate I/O-bound tasks (like database queries, file reads, or external API calls) to the OS or thread pool, then moves on to the next request without waiting.

So, when 10,000 users hit your “Buy Now” endpoint:

Each request enters the event loop.
If the request involves a database query, Node.js offloads that work and immediately starts handling the next request.
When the database responds, Node.js picks up where it left off and sends the response.

This is why Node.js can handle thousands of concurrent connections—even on a single thread.

But here’s the catch: if your code blocks the event loop, everything grinds to a halt.

Where Things Actually Break: The Bottlenecks

Under heavy load, your API doesn’t just fail for no reason—it fails because of bottlenecks. Here are the most common ones:

- Blocking the Event Loop - If your code does something CPU-heavy in JavaScript—like encrypting passwords synchronously, parsing huge JSON payloads, or running complex calculations—it blocks the event loop. While that one request is hogging the thread, all other requests wait. This is why you should never use fs.readFileSync or heavy crypto in production code.

- Database Connection Pool Exhaustion – Your database doesn’t have infinite connections. Most connection pools are configured to handle 10–100 concurrent connections. If 10,000 requests each try to open a new connection, your pool gets exhausted. Requests start queuing—or worse, failing with “too many connections” errors.

- Unindexed or Slow Queries – A single slow query can block hundreds of requests waiting on the same table. Under load, this becomes a cascade failure: one slow query → connection pool fills up → new requests timeout → users see errors.

- External API Calls Without Timeouts – If your “Buy Now” endpoint calls a payment gateway, inventory service, or shipping API—and those calls don’t have timeouts—your server can get stuck waiting for responses that never come. Multiply that by 10,000 requests, and you’ve got a server meltdown.

- Memory Pressure and Garbage Collection – Under heavy load, your server allocates more memory. If you’re not careful, you can trigger frequent garbage collection pauses, which block the event loop and spike latency.

The Hidden Threat: Race Conditions

One of the most dangerous—and subtle—problems that emerges under high concurrency is the race condition. This occurs when two or more requests try to modify the same data simultaneously, and the final result depends on the unpredictable order in which the operations complete.

Consider this classic e-commerce example:

Without proper safeguards, two users can both be told an item is in stock, both complete checkout, and both be charged—even though only one unit was available. This is a race condition in its purest form, and it’s exactly why you need the strategies we’ll cover next.

So, What Actually Happens When 10,000 Users Click “Buy Now”?

Let’s walk through the sequence step by step.

Step 1: Requests Hit the Load Balancer Your traffic doesn’t hit a single server—it hits a load balancer (like AWS ALB, NGINX, or Cloudflare). The load balancer distributes requests across multiple backend instances. If you don’t have a load balancer, all 10,000 requests hit one server. That server will likely crash.

Step 2: Each Request Enters the Event Loop On each backend instance (say, a Node.js server), requests enter the event loop. If your code is non-blocking, the server can handle thousands of concurrent requests per instance.

Step 3: Database Queries Are Executed Each request tries to:

Check inventory
Reserve the item
Process payment
Create an order record

If your database isn’t optimized (no indexes, no connection pooling, no read replicas), this is where things slow down—and where race conditions can wreak havoc.

Step 4: Responses Are Sent Responses don’t go out in the order the requests arrived. They go out as soon as each request completes. Some users get their order confirmation in 200ms. Others wait 10 seconds. A few get timeouts.

How to Design for 10,000 Concurrent Users

You don’t need to over-engineer for day one—but you do need to design for scale. Here’s how:

1. Use Connection Pooling

Configure your database client (like pg for PostgreSQL or mysql2 for MySQL) to use a connection pool. This reuses connections instead of creating new ones for every request.

2. Database-Level Locking

The most direct fix lives at the database layer, using row-level locks. A SELECT ... FOR UPDATE statement tells the database: “Lock this specific row until my transaction finishes—nobody else can read or write it until I’m done.”

Any other transaction trying to touch row 42 simply blocks until this one commits or rolls back. This guarantees correctness, but it introduces lock contention—under extreme concurrency, requests start queuing up waiting for locks, and latency climbs. For a single hyper-popular SKU, this can become a serious bottleneck even though the rest of your database is sitting idle.

An alternative is optimistic locking, which skips the lock entirely and instead checks a version number at write time:

3. Decoupling with Queues

Locking solves correctness at the cost of making requests wait synchronously. A more scalable pattern is to decouple the write from the request entirely using a message queue (Kafka, RabbitMQ, AWS SQS, Google Pub/Sub).

Instead of your API handler directly touching the database:

The incoming request is validated and dropped onto a queue as a message: { userId, productId, requestId }.

The API immediately responds with something like 202 Accepted — processing.

A pool of background workers consumes messages off the queue one at a time (or a few at a time) at a rate the database can actually sustain.

Each worker executes the actual stock-check-and-deduct logic inside a transaction.

The result (success/failure) gets pushed to the client via websocket, polling, or a notification.

This converts a spike of 10,000 simultaneous writes into a controlled, sequential stream that the database can process without falling over. The tradeoff is eventual consistency—there’s a small delay between “I clicked buy” and “the system confirms it,” which needs to be communicated clearly in the UI (Spinners) so it doesn’t feel broken.

But here’s the reality check: Would you really place all 10,000 requests into Kafka? Not necessarily. Because if you only have 100 units in stock, 99% of those requests are doomed to fail from the start. Dropping them into a queue only wastes worker capacity, memory, and network bandwidth.

That’s why large-scale flash-sale systems move inventory protection closer to the edge. They preload inventory into a fast in-memory store (like Redis) and use it as a first gate. If Redis says stock = 0, the request is rejected immediately with a polite "Out of Stock" message, never even touching the queue or the primary database. The queue becomes a pathway only for requests that actually have a fighting chance, keeping your workers lean and your database unscathed.
Add a Caching Layer

4. Add a Caching Layer

For read-heavy traffic—like thousands of users just checking if a product is in stock before deciding to buy—a cache (Redis, Memcached, or a CDN edge cache) intercepts most of that traffic before it ever reaches the database. Re-running the same read query 10,000 times a second against your primary database is pure waste.

In high-concurrency “Buy Now” scenarios, Redis can go further and act as the first gate. Many flash-sale systems preload the available inventory into Redis at the start of the sale. When a request arrives, the first thing the API does is try an atomic decrement:

DECR product:42:stock

If the value was still positive, the request is allowed to proceed (and later confirmed in the database). If Redis returns a value less than zero, the request is rejected immediately with an “Out of Stock” response. It never reaches Kafka, never reaches the database, and never wastes a connection. This is extremely fast and protects the rest of your system.

But… What if Redis crashes after decrementing the stock?

This is why Redis should never be your source of truth. It’s a traffic-shaping layer - an early filter that keeps the stampede from overwhelming the slower, more authoritative systems behind it, not the final authority. The database remains the single source of truth for inventory. If Redis goes down mid-sale, you lose your fast gate, but your database can still fall back on its own row-level locks and atomic updates to guarantee correctness.

However, The classic hard problem remains: cache invalidation. A stale cache can tell users an item is available when it just sold out. That’s why the Redis inventory numbers are usually treated as a temporary, short-lived view that is reconciled with the database on a short interval or after every successful write.

5. Use Atomic Operations Instead of Read-Then-Write

A lot of race conditions disappear entirely if you avoid the "read, then write" pattern altogether and push the arithmetic into the database itself:

This single statement is atomic. The database guarantees that the check and the decrement happen together. Suppose the last item has stock = 1 and two requests arrive at almost the same instant:

Request A’s UPDATE succeeds. Stock becomes 0.
Request B’s UPDATE finds stock > 0 is now false, so zero rows are updated. The request is rejected.

No overselling. Only one transaction can successfully claim the final unit.
That’s the pure inventory decrement.

But here’s where it gets messy. What if you decrement the stock successfully, but the payment gateway times out? Or the user's credit card declines? Or they close their browser mid-checkout?

Imagine this: Stock is 1. User A reserves it. Your atomic UPDATE sets stock to 0. Then the payment fails. Now the product is completely unavailable—even though nobody actually bought it. You've just locked away your last item for a failed transaction. That's a terrible customer experience.

Large e-commerce platforms solve this by separating reservation from purchase. Instead of permanently deducting stock at the start of checkout, inventory first moves into a temporary, time-bound reserved state. The stock stays reserved while the user completes payment, but it's not permanently gone yet.

Only after a successful payment confirmation does the reservation convert into a permanent sale. If the payment fails, or if the user abandons the cart and walks away, the reservation simply expires—say, after 5-10 minutes—and the inventory is atomically released back into the available pool for the next customer.

This two-phase approach adds a bit of complexity (you now need a background job to sweep expired reservations), but it prevents the heartbreaking scenario where a legitimate buyer is told "out of stock" because someone else's credit card just bounced. It turns your atomic operation from a blunt instrument into a surgical tool—and your users will notice the difference.

6. Idempotency Keys

Under load, clients retry. Networks flake, timeouts happen, users double-click. Without protection, this creates duplicate side effects—double charges, double stock deductions.

The standard fix is an idempotency key: a unique identifier generated client-side (often a UUID) and attached to the request. The server stores which idempotency keys it has already processed and, on seeing a repeat, returns the cached original response instead of re-executing the logic:

Stripe/Paystack’s API is the canonical real-world example of this pattern done well—it’s specifically designed so that retried payment requests never double-charge a customer, as long as the same idempotency key is reused.

7. Rate Limiting and Backpressure

Not every request deserves to reach your database at full speed. Rate limiting—using algorithms like token bucket or sliding window—caps how many requests per second a given user, IP, or API key can send, rejecting or delaying the rest with a 429 Too Many Requests response.

This isn’t just about abuse prevention—it’s about protecting your own infrastructure. Related to this is backpressure: a signal that flows backward through a system telling upstream components “slow down, I can’t keep up,” so instead of a slow database causing your API servers to pile up thousands of stalled connections and crash, the system degrades gracefully by shedding or delaying excess load.

No Single Solution Solves the Entire Problem

No single technique here solves the whole problem. Locking without queuing creates painful contention. Queuing without idempotency creates duplicate charges. Caching without invalidation lies to users. And none of this work if you haven’t addressed the underlying race conditions that concurrency exposes.

It’s the combination—each one solving a different failure mode—that lets a system survive a genuine 10,000-request stampede without corrupting data or falling over.

Conclusion: Why This Matters for You

As a backend developer, your job isn’t just to write code that works. It’s to write code that works under pressure.

When you understand what happens when 10,000 users hit your API, you stop thinking in terms of “my code” and start thinking in terms of systems. You ask:

What happens if this endpoint gets 100x more traffic?

Where are the bottlenecks?

How do I fail gracefully?

What metrics should I monitor?

This mindset shift is what makes you valuable in remote job markets, freelance gigs, and high-growth startups.

From Spaghetti to Structure: The Architecture Patterns Every Software Developer Should Know

Nsikan Patrick Adaowo — Mon, 27 Jul 2026 16:31:00 +0000

Ever inherited a codebase where changing one thing breaks five others?

That’s rarely a coding problem. It’s an architecture one.

When you first join a software team, code organization feels simple. You put database queries in one folder, business logic in another, and UI routes at the top. It feels clean and logical.

Then the product hits real-world scale.

Deadlines tighten. Business models pivot based on user behaviour. Features get tacked on hastily over frantic weekends. What started as an elegant codebase slowly evolves into a tangled, unpredictable web.
Adding a simple feature to your checkout flow unexpectedly breaks an analytics pipeline three modules away. You realize you haven’t built a resilient application—you’ve built a house of cards.

Most developers assume the fix is writing more utilities or refactoring syntax. But syntax doesn’t solve structural decay; architecture does.

Software architecture patterns aren’t academic exercises or trivia for senior engineering interviews. They are time-tested blueprints designed to manage complexity, preserve developer velocity, and protect systems from falling apart when requirements change.

Here’s what every developer should understand:

The Real Cost of Spaghetti

Spaghetti architecture doesn’t just make the code ugly. It makes the business slower. Features take longer. Bugs become more expensive. Good engineers start avoiding certain parts of the codebase. New hires take months instead of weeks to become productive. And eventually, someone suggests a full rewrite — which is usually just a more expensive way of making the same mistakes again.

Most of this pain comes from missing or poorly enforced boundaries. When the UI can talk directly to the database, when domain logic lives inside controllers, when services depend on concrete implementations instead of abstractions, the system becomes a ball of mud. Change anything and the mud shifts.

Architecture patterns are essentially agreements about where those boundaries should live and what is allowed to cross them.

Here is a definitive guide to the 10 core architectural patterns, broken down by how they actually function in production:

1. Layered (N-Tier) Architecture

The Standard Horizontal Separation

Layered architecture is the default structure of almost every traditional backend framework. It divides an application horizontally into stacked tiers—typically Presentation, Business Logic, and Data Access—where each layer only talks to the one directly below it.

- How it works in practice:
A user hits an endpoint, the Controller parses the request, hands it off to the Service layer to execute business rules, and the Service calls the Repository to write to the database.

- The Reality Check:
While easy to learn, as your app grows, adding a single feature (like a user preference toggle) requires touching every single layer. Over time, layers become “pass-through tax boundaries” where code just forwards data downward without adding value.

2. Hexagonal Architecture (Ports & Adapters)

Isolating Core Business Logic from External Tech

Hexagonal Architecture (also known as ports and adapters) flips the traditional hierarchy inside out. Instead of placing the database at the bottom, it places your core domain logic at the exact center. The core defines abstract Ports (interfaces for what it needs—like PaymentGateway or UserRepository), and external technologies implement those ports using Adapters.

- How it works in practice:
Your core ordering logic doesn’t care if payments go through Paystack or Stripe, or if data lands in PostgreSQL or MongoDB. It only talks to its internal Port contracts. In other words, your application should not depend on external things. External things should depend on your application.

- The Reality Check:
You can test your entire business logic in milliseconds without spinning up a database or mocking complex HTTP calls. The trade-off is writing extra interface boilerplate up front.

3. Onion Architecture

Concentric Rings of Dependency Control

Coined by Jeffrey Palermo, Onion Architecture builds on the same principle as Hexagonal, visualization-wise using concentric circles. Domain Entities sit at the very core, surrounded by Domain Services, then Application Services, with Infrastructure and UI residing on the outermost ring.

How it works in practice: The strict rule of Onion Architecture is that dependencies only point inward. Outer rings depend on inner rings, but inner rings never know anything about outer rings.

- The Reality Check:
It keeps your core domain pristine and framework-agnostic. However, engineers used to quick-and-dirty scripting might find navigating multiple concentric abstraction layers over-engineered for simple CRUD applications.

4. Clean Architecture

Uncle Bob’s Unified Structural Blueprint

Popularized by Robert C. Martin (”Uncle Bob”), Clean Architecture synthesizes Hexagonal and Onion principles into a single, standardized framework. It categorizes code into Entities (enterprise business rules), Use Cases (application business rules), Interface Adapters, and Frameworks/Drivers. The Dependency Rule is the key: source code dependencies can only point inward. Nothing in an inner circle can know about something in an outer circle.

- How it works in practice: Use Cases orchestrate the flow of data to and from Entities. Frameworks (like Next.js, NestJS, or Express) live in the outermost layer as disposable details.

- The Reality Check: It provides absolute clarity on where code belongs. The downside? It can lead to an explosion of files and mappings between DTOs (Data Transfer Objects) and Domain Entities for basic operations. Not every CRUD app needs full Clean Architecture ceremony. The value shows up when the business rules are complex and long-lived. If your domain logic is simple, a lighter approach often wins. The principle, however — protect the business rules from frameworks and delivery mechanisms — remains solid.

5. Vertical Slice Architecture

Feature-First Autonomy Over Layered Overhead

Instead of slicing the app horizontally by technical concern (Controllers, Services, Repositories), Vertical Slice Architecture cuts vertically by business feature or use case (e.g., CreateOrder, CancelSubscription).

- How it works in practice: Every feature slice is completely self-contained. It owns its endpoint, request handling, business logic, and database access.

- The Reality Check: It drastically reduces side-effect risks—modifying CreateOrder can never accidentally break CancelSubscription because they share no execution paths. It is arguably the most effective pattern for shipping products fast without technical debt.

6. Event-Driven Architecture (EDA)

Asynchronous Communication via Reactive Events

In an Event-Driven system, services don’t make direct, blocking calls to each other. Instead, when a state change occurs, a service emits an Event to a central broker (like Kafka or EventBridge). Other independent services subscribe to those events and react accordingly.

- How it works in practice: When a user checks out, the Order Service emits OrderPlaced. The Inventory Service listens and reserves stock; the Notification Service listens and emails a receipt; the Analytics Service logs the event.

- The Reality Check: It decouples services almost entirely, allowing systems to handle massive asynchronous traffic spikes. The catch? Debugging distributed event chains and handling eventual consistency can be difficult without robust observability. But for many domains, the flexibility is worth the effort.

7. CQRS (Command Query Responsibility Segregation)

Splitting Write Operations from Read Pipelines

CQRS fundamentally splits an application’s data operations into two distinct pathways: Commands (writes that alter state) and Queries (reads that fetch data).

- How it works in practice: The write side focuses heavily on business rules and transactional integrity (using a normalized database). The read side bypasses complex business logic entirely, reading pre-aggregated views from a fast search index or cache.

- The Reality Check: It solves extreme performance bottlenecks when read traffic dwarfs write traffic (e.g., social media feeds, e-commerce catalogs). However, running two database models introduces temporary data lag (eventual consistency).

8. Service-Oriented Architecture (SOA)

Enterprise-Wide Shared Business Capabilities

Predating modern microservices, SOA is an architectural style where an enterprise splits its core systems into distinct, reusable services that communicate over a centralized communication bus—historically an Enterprise Service Bus (ESB).

- How it works in practice: A centralized ESB handles message transformation, routing, and protocol conversion between large, enterprise-level services (like Billing, ERP, and CRM).

- The Reality Check: SOA allowed massive enterprises to integrate disparate legacy systems. However, the central ESB often turned into a heavy, monolithic bottleneck managed by a single team.

9. Microservices Architecture

Independently Deployable, Fine-Grained Services

Microservices take the core idea of service decomposition and decentralize it completely. The application is built as a suite of small, autonomous services, each owning its own business domain, repository, and deployment pipeline.

- How it works in practice: Instead of sharing a monolithic database, the User Service, Payment Service, and Catalog Service each run their own isolated databases and communicate over lightweight protocols (gRPC or REST).

- The Reality Check: Microservices enable large organizations to scale engineering teams independently. But for small teams, they trade simple code problems for complex distributed network, deployment, and tracing problems.

- The promise is attractive: independent deploy-ability, technology freedom, team autonomy, better scaling. But you trade a simple deployment problem for a distributed systems problem. Network latency, partial failures, eventual consistency, distributed transactions, observability, and operational complexity all showing up at the same time.

10. Serverless Architecture

Function-as-a-Service & Managed Infrastructure

Serverless shifts the entire burden of server management, scaling, and provisioning to cloud providers. You write stateless granular functions (like AWS Lambda) that execute purely in response to triggers or HTTP requests.

- How it works in practice: When an API route is called, the cloud provider spins up a lightweight execution environment, runs your function, returns the response, and immediately destroys or freezes the container.

- The Reality Check: You pay strictly for execution time down to the millisecond, and elasticity is virtually infinite out of the box. The main trade-offs are potential cold-start latencies and vendor lock-in.

So, What Actually Matters in Practice

- Boundaries beat cleverness: Clear ownership and limited knowledge between parts of the system matter more than any specific pattern name.

- Start simple, evolve deliberately: A modular monolith with good internal boundaries is often the best place to begin. Extract services or introduce events when the pain of not doing so becomes clear.

- Patterns are tools, not identities:
Saying “we do Clean Architecture” or “we are event-driven” is less useful than understanding the problems each pattern solves and the costs it introduces.

- Consistency of approach matters more than perfection: A codebase that applies one set of principles reasonably well is usually healthier than one that mixes five different architectural styles without clear rules.

- Architecture is a team sport: The best patterns fail if the team doesn’t understand or respect the boundaries. Documentation, code reviews, and shared language matter.

The Product Engineering Mindset: Architectural Balance

It’s easy to get seduced by the distributed power of CQRS, Event-Driven processing, and Serverless. But every architectural pattern introduces trade-offs:

- Eventual Consistency: Reads may lag behind writes by a few milliseconds.

- Operational Overhead: Managing message brokers, dead-letter queues, and schema migrations requires real infrastructure discipline.

A true product engineer doesn’t apply CQRS and Event-Driven systems everywhere. They isolate them to the specific 10% of their application that faces intense write contention or heavy async processing, while keeping the rest of the application simple.

Scale where it counts, simplify where you can, and keep the user experience at the center of every architectural choice; because architecture isn’t about finding the “best” pattern; it’s about choosing the right set of trade-offs for your current scale.

Your Code is a Reflection of Your Standards

Nsikan Patrick Adaowo — Mon, 20 Jul 2026 22:27:34 +0000

For a long time, I believed becoming a better developer was simply a matter of writing more code.
The formula seemed straightforward and mechanical: Learn a language. Build a project. Complete a course. Move on to the next framework. Repeat.

For a while, that high-velocity approach worked surprisingly well. Every new feature taught me something. Every bug forced me to dive into documentation files. Every tutorial introduced another technology that felt exciting.

But as I began transitioning deeper into product engineering, I noticed a strange paradox.
Although I was learning new tools constantly, I wasn't becoming dramatically better at solving real-world problems. I could spin up an application. I could create an API. I could design a relational database. Yet, whenever I looked at systems designed by experienced product engineers, their work felt fundamentally different.
Not because it was more complex. Actually, it was usually much simpler.

Their architecture was easier to reason about. Their projects had strategic restraint. Their decisions seemed completely intentional. Somehow, they weren't just writing software; they were designing an asset.

For months, I assumed this clarity came from sheer years on the job. Eventually, I realized something else was happening. The senior engineers I admired didn't just look at documentation or scroll through technical blog posts. They read books that forced them to think deeply about system dynamics and human context.

Right now, I am reading Clean Code by Robert C. Martin. It is a text many took for granted during the "vibe coding" boom, but in 2026, its principles have become an aggressive competitive advantage.

Before picking up this book, my primary goal as a developer was shortsighted: Make the program work.

If the application produced the correct output and the UI looked clean, I considered the task complete. I was focused on the "surface."
Clean Code forces you to look at the "subsurface."

Software rarely lives for a week or a month. In a startup environment, a product survives, evolves, and shifts over years. This means the code you ship today will be read, modified, and debugged far more often than it is written. Uncle Bob reminds us of a truth that every product engineer must internalize: Programming isn’t just communication with a compiler; it’s communication with people.

One specific concept that shifted my mindset was the philosophy behind naming. On the surface, variable naming sounds trivial. The computer doesn’t care if a variable is named t or total. They produce identical machine code.
But a product engineer doesn't build for the machine; they build for the team and the user. One variable forces future developers to guess; the other tells a story.

When you have to touch a codebase six months later to pivot a feature based on customer feedback, clear naming is the difference between an elegant iteration and a broken system.

Clean Code challenged my habits. Functions that stretched over hundreds of lines suddenly looked like architectural debt. Comments became a symptom of poor expression rather than a sign of good documentation. Complex conditional logic became something to simplify, not tolerate.

As a product engineer, I’m glued already. This book has permanently changed how I review my own work. I no longer just ask, "Does this run?" I now ask, "Will another developer understand the intent behind this system without needing a meeting?"

The tools and frameworks change every two months, but the fundamentals of building a sustainable system remain permanent. Clean Code isn't teaching you a tool; it’s training your judgment.