DEV Community: Anik Sikder

How Should You Structure a Software Architecture?

Anik Sikder — Fri, 21 Aug 2026 17:16:27 +0000

Hey developers! 👋

Welcome back to the journey from business requirements to production-ready systems.

A founder walks into a development team and says:

"We need an ERP."

Sounds simple.

Until you start asking questions.

Where should users live?

How should organizations work?

Who owns inventory?

Where should orders be created?

Who is allowed to approve invoices?

What happens when thousands of users start using the dashboard?

Where should business rules live?

Should everything be one application?

Should we use microservices?

And eventually:

How do we build today's system without making tomorrow's system painful to change?

That's where software architecture begins.

Not with Kubernetes.

Not with Kafka.

Not with microservices.

Not even with Django vs FastAPI.

It begins with understanding what the business actually needs to do.

Let's build the architecture from that starting point.

The First Mistake: Starting With Technology

Imagine the product team gives you an ERP requirement.

A common engineering conversation might immediately become:

Django or FastAPI?

PostgreSQL or MongoDB?

Redis?

Kafka?

RabbitMQ?

Kubernetes?

Microservices?

These are valid questions.

But they're not the first questions.

The first question is:

What responsibilities does this business actually have?

An ERP might need:

ERP
│
├── Identity
├── Organizations
├── Products
├── Inventory
├── Sales
├── Purchasing
├── Billing
├── Reporting
└── Notifications

Notice something important.

These aren't technologies.

They're business capabilities.

That distinction changes how we design the entire system.

Step 1: Discover the Business Capabilities

Start by talking about what the system does.

For example:

The business needs to:

Manage employees
Manage organizations
Track products
Track inventory
Create sales orders
Handle purchasing
Generate invoices
Process payments
Produce reports
Send notifications

Now the system has a shape.

Instead of starting with:

controllers/
models/
views/
utils/
helpers/
services/

we can start with:

identity/
organization/
inventory/
sales/
purchasing/
billing/
reporting/

Why is this useful?

Because someone joining the project six months later can understand the product by looking at its structure.

The code starts reflecting the business.

And that's a powerful architectural principle:

Organize around meaningful responsibilities before organizing around technical abstractions.

Step 2: Find the Boundaries

Identifying capabilities isn't enough.

We also need to determine where one responsibility ends.

Consider an order.

An order depends on products.

Inventory also depends on products.

Billing depends on orders.

Reporting may depend on almost everything.

If every module directly knows about every other module, we eventually get something like:

Sales ───────► Inventory
  │              │
  ▼              ▼
Billing ◄──── Products
  │              │
  └──────► Reporting
       ▲
       │
   Identity

At first, this feels convenient.

Need something from another module?

Just import it.

But eventually:

Change Inventory
      ↓
Break Sales
      ↓
Break Reporting
      ↓
Fix Five Other Modules

The problem isn't that the system has many modules.

The problem is that the responsibilities aren't properly isolated.

A healthier model is:

Identity
   │
   └── Who is this user?

Organization
   │
   └── Which business does the user belong to?

Inventory
   │
   └── What resources do we have?

Sales
   │
   └── What are we selling?

Purchasing
   │
   └── What are we buying?

Billing
   │
   └── What do we charge?

Reporting
   │
   └── What happened?

Each area has a reason to exist.

That's what a boundary should accomplish.

A boundary is not just a folder. It defines ownership.

Step 3: Architecture Is About Ownership

Let's take a very normal operation:

A customer places an order.

From the outside:

POST /orders

Looks simple.

Internally, it could involve:

Authenticate User
      ↓
Resolve Organization
      ↓
Check Membership
      ↓
Authorize Action
      ↓
Validate Request
      ↓
Validate Products
      ↓
Check Inventory
      ↓
Calculate Price
      ↓
Apply Discount
      ↓
Create Order
      ↓
Update Inventory
      ↓
Create Financial Records
      ↓
Record Audit Event
      ↓
Trigger Notifications

A beginner might put all of this inside:

CreateOrderView

Something like:

CreateOrderView
│
├── authenticate()
├── authorize()
├── validate()
├── check_inventory()
├── calculate_price()
├── apply_discount()
├── create_order()
├── update_inventory()
├── create_invoice()
├── write_audit()
├── send_email()
└── response()

It works.

Until the application grows.

The API layer slowly becomes the place where the entire business lives.

That's when architecture starts becoming difficult to maintain.

A better separation looks like:

HTTP Request
     │
     ▼
API Layer
     │
     ▼
Application Service
     │
     ▼
Domain Rules
     │
     ▼
Persistence
     │
     ▼
Database

Now each layer has a different responsibility.

API Layer

Understands:

HTTP
Requests
Responses
Status Codes
Serialization

Application Service

Understands:

What use case are we executing?

Domain Logic

Understands:

What rules must always remain true?

Persistence

Understands:

How do we read and write data?

Database

Protects:

Data integrity
Constraints
Transactions
Indexes
Relationships

The objective isn't more layers.

The objective is clear ownership.

Follow the Request Instead of Staring at the Diagram

Architecture diagrams can become abstract very quickly.

A better way to understand a system is to follow an actual request.

Imagine the user clicks:

Create Order

The request could travel through:

Client
  │
  ▼
API
  │
  ▼
Authentication
  │
  ▼
Authorization
  │
  ▼
Validation
  │
  ▼
CreateOrderService
  │
  ├── Product Validation
  ├── Inventory Check
  ├── Price Calculation
  └── Order Creation
  │
  ▼
Database Transaction
  │
  ▼
Order Created
  │
  ▼
Domain Event
  │
  ├── Audit
  ├── Notification
  └── Analytics

Now architecture becomes easier to reason about.

Every component has a purpose.

This gives us another useful rule:

If you cannot explain why a component exists in the request journey, question whether you need that component.

Turning Boundaries Into Code

Once the business boundaries are clear, we can map them into the project.

For example:

backend/
│
├── apps/
│   │
│   ├── identity/
│   │   ├── models/
│   │   ├── services/
│   │   ├── permissions/
│   │   └── api/
│   │
│   ├── organization/
│   │   ├── models/
│   │   ├── services/
│   │   ├── permissions/
│   │   └── api/
│   │
│   ├── inventory/
│   │   ├── models/
│   │   ├── services/
│   │   ├── repositories/
│   │   └── api/
│   │
│   ├── sales/
│   │   ├── models/
│   │   ├── services/
│   │   ├── repositories/
│   │   └── api/
│   │
│   ├── purchasing/
│   ├── billing/
│   └── reporting/
│
├── shared/
│   ├── authentication/
│   ├── authorization/
│   ├── exceptions/
│   ├── logging/
│   └── utilities/
│
├── infrastructure/
│   ├── database/
│   ├── cache/
│   ├── messaging/
│   ├── storage/
│   └── email/
│
└── config/

The important part isn't the exact folder names.

It's the reasoning behind them.

We didn't say:

"Every application needs repositories."

We first asked:

"What are the responsibilities?"

Then we created a structure that reflects those responsibilities.

What Belongs Inside a Module?

Let's zoom into sales.

A possible module might look like:

sales/
│
├── models/
├── services/
├── repositories/
├── permissions/
├── events/
├── validators/
└── api/

But folders alone don't create architecture.

Each part needs a purpose.

API

The API is the system's external boundary.

It handles:

HTTP Requests
Validation Input
Serialization
HTTP Responses
Status Codes

It translates external communication into application operations.

It should not become the entire business engine.

Application Services

Services should represent meaningful operations.

For example:

CreateOrderService
ConfirmOrderService
CancelOrderService
RefundOrderService

A useful question is:

What business operation does this service represent?

If the answer is unclear, the abstraction may not be useful.

Domain Logic

This is where business rules belong.

For example:

An order cannot be cancelled after shipment.

Inventory cannot become negative.

A finalized invoice cannot be edited.

Only an authorized organization owner can transfer ownership.

These aren't HTTP concepts.

They're business rules.

They should remain as independent from the delivery mechanism as practical.

Persistence

Persistence handles data access.

For example:

find_order()
find_product()
save_order()
get_inventory()

Its responsibility is retrieving and storing information.

It shouldn't decide:

"Is this customer allowed to cancel the order?"

That's a business decision.

Don't Turn Everything Into a Service

There's another architectural trap.

Once developers discover service classes, everything becomes a service:

UserService
ProductService
OrderService
EmailService
DatabaseService
ValidationService
HelperService
ManagerService
UtilsService

Soon the codebase has hundreds of abstractions.

But abstraction isn't automatically architecture.

The objective isn't:

More classes.

It's:

Clearer responsibilities.

Before introducing a service, ask:

What meaningful business capability or use case does this component represent?

Architecture should reduce cognitive load.

Not create another maze for developers to navigate.

The Database Is Not "Just Storage"

One of the biggest architectural mistakes is treating the database as a passive storage box.

For business systems, the database is part of the architecture.

Take inventory.

A simplistic model might store:

Product
quantity = 500

But where did those 500 units come from?

Maybe:

Purchase
Sale
Return
Transfer
Adjustment
Damage

If we only store the current number, we've lost the history.

A stronger model records inventory movements:

Product
   │
   ▼
Inventory Movement
   │
   ├── Purchase
   ├── Sale
   ├── Return
   ├── Adjustment
   └── Transfer

Now the system can answer two very different questions:

How much inventory do we have?

and:

Why do we have this amount?

That second question becomes critical for:

auditing
reconciliation
reporting
debugging
financial accuracy

So database architecture is more than:

API → Database

It is closer to:

Business Rules
      ↓
Data Model
      ↓
Transactions
      ↓
Constraints
      ↓
Indexes
      ↓
Persistence

A good data model doesn't merely store information.

It helps protect the business.

Transactions: Keeping Business Operations Consistent

Consider order creation.

We may need to perform:

Create Order
Reduce Inventory
Create Financial Record

Now imagine:

Order       → Success
Inventory   → Success
Financials  → Failure

The system is inconsistent.

The order exists.

Inventory changed.

But the financial record didn't.

For operations that must succeed or fail together, we need a transactional boundary:

Transaction
│
├── Create Order
├── Update Inventory
└── Create Financial Record

Either:

Everything succeeds

or:

Everything rolls back

But there's an important architectural distinction.

Not every operation belongs inside the transaction.

Sending an email doesn't normally need to hold the database transaction open.

Generating a large PDF doesn't either.

Sending analytics data may not need to block the user.

That leads naturally to asynchronous processing.

Some Work Should Happen Later

Imagine a user creates an order.

Do they really need to wait while the system:

Send Email
Generate PDF
Update Analytics
Notify Warehouse
Sync External System

Probably not.

The user mainly needs one answer:

Was my order created successfully?

So the system can separate critical work from background work:

Create Order
     │
     ▼
Database Transaction
     │
     ▼
Order Created
     │
     ▼
Return Response

Then:

Order Created Event
        │
        ├── Send Email
        ├── Generate Invoice
        ├── Update Analytics
        ├── Notify Warehouse
        └── Sync External System

Queues and workers become useful here.

But notice the reasoning.

We didn't begin with:

"Let's install RabbitMQ."

We began with:

"Which work should not block the user's request?"

That's the architectural decision.

Synchronous vs Asynchronous Processing

A simple rule of thumb:

Keep work synchronous when:

the user needs the result immediately
the operation is relatively fast
immediate consistency matters

For example:

Create Order
Validate Payment
Update Inventory

Consider asynchronous processing when:

the operation is slow
the user doesn't need the result immediately
it can be retried
an external system is involved
the work is computationally expensive

For example:

Generate Large Report
Send Bulk Emails
Export Millions of Records
Process Large Files
Synchronize External Data

The lesson isn't:

"Always use queues."

It's:

Choose synchronous or asynchronous processing based on the characteristics of the work.

Authentication Isn't Authorization

As the ERP grows, we need to know who is making a request.

That's authentication.

But identity alone isn't enough.

We also need to know what that person can do.

That's authorization.

A typical enterprise request might look like:

User
  ↓
Organization Membership
  ↓
Role
  ↓
Permissions

For example:

A manager might have:

invoice.view
invoice.create
inventory.view
inventory.adjust

While another employee may only have:

inventory.view
order.create

So remember:

Authentication asks:

Who are you?

Authorization asks:

What are you allowed to do?

Those are different architectural concerns.

Multi-Tenancy Changes Everything

Now let's turn our ERP into a SaaS platform.

Instead of one company, we have:

Organization A
Organization B
Organization C
...
Organization 500

The security question changes.

It is no longer simply:

Can this user access this order?

It becomes:

Can this user, inside this organization, perform this action on this resource?

The request might therefore follow:

Request
   ↓
Authenticate User
   ↓
Resolve Organization
   ↓
Verify Membership
   ↓
Authorize Action
   ↓
Query Tenant-Scoped Data

The database should reinforce this boundary.

For example:

Order
│
├── id
├── organization_id
├── customer_id
└── total

Now the order belongs to a specific organization.

This is more than a feature.

Tenant isolation is an architectural security boundary.

A failure here can expose one customer's information to another customer.

That's why multi-tenancy should be considered during architectural design, not bolted on later.

APIs Are Contracts, Not Just Endpoints

The internal architecture may change many times.

Clients shouldn't need to know about those internal changes.

A web application shouldn't care whether the backend uses:

PostgreSQL
Redis
Workers
A Monolith
Microservices
A Message Broker

It should communicate through a stable contract:

Web App
     │
Mobile App
     │
Partner
     │
Internal Tool
     │
     ▼
    API
     │
     ▼
Application

That's why API design matters.

An API is a contract between:

clients
developers
internal teams
partners
future products

A strong API allows internal implementation to evolve without forcing every consumer to understand the internal architecture.

Then Reality Happens: Performance Problems

Eventually the ERP grows.

The dashboard becomes popular.

A request such as:

GET /dashboard

might perform:

20 database queries
3 aggregations
5 joins
2 external requests

Now thousands of users hit the same endpoint.

The database becomes a bottleneck.

The obvious response might be:

"Add more database servers."

But first ask:

Are we calculating the same information repeatedly?

If yes, caching might help.

Request
   │
   ▼
Cache
   │
   ├── Hit ──────► Response
   │
   └── Miss
        │
        ▼
     Database
        │
        ▼
    Store Cache
        │
        ▼
     Response

But caching creates new architectural questions:

How long should data remain cached?

When should it expire?

When should it be invalidated?

Is stale data acceptable?

What happens if the cache is unavailable?

What information is safe to cache?

So don't add a cache because:

"Scalable systems use Redis."

Add caching because:

A measured workload shows that caching solves a real problem.

Observability: When Production Starts Talking

Eventually someone will tell you:

"The API is slow."

Now what?

You need to answer:

Which endpoint?

Which request?

Which user?

Which organization?

How long did it take?

Which database query was slow?

Was it a cache miss?

Did the queue become overloaded?

Did an external service fail?

That's observability.

A useful request context might include:

request_id
user_id
organization_id
endpoint
status
duration

And the three familiar pillars are:

Logs
Metrics
Traces

Logs

Tell you what happened.

Metrics

Tell you how frequently and severely something is happening.

Traces

Show where time was spent across a request.

Without observability, production debugging becomes:

Something is slow.

Something is broken.

Maybe restart the server?

That's not an architecture strategy.

Infrastructure Comes After the Application

Only after understanding the application should infrastructure decisions become concrete.

A reasonable production starting point might look like:

                    Internet
                       │
                       ▼
                 Load Balancer
                       │
                       ▼
                   API Servers
                  /     |      \
                 /      |       \
                ▼       ▼        ▼
          PostgreSQL   Redis   Object Storage
                           │
                           ▼
                      Message Queue
                           │
                           ▼
                         Workers

Around that system:

CI/CD
Monitoring
Logging
Tracing
Backups
Secrets Management
Alerts

Now each component has a reason.

PostgreSQL       → business data
Redis            → selected fast-access workloads
Object Storage   → files
Message Queue    → asynchronous coordination
Workers          → background processing
Monitoring       → system health
CI/CD            → safe delivery

This is much healthier than creating a diagram with 25 technologies first and then trying to invent reasons for them.

Should You Start With Microservices?

Eventually, someone will probably say:

"We should use microservices."

Maybe.

But let's look at the context.

Suppose the company has:

5 Developers
1 Product
10 Customers

And we introduce:

User Service
Product Service
Order Service
Inventory Service
Billing Service
Notification Service
API Gateway
Service Mesh
Message Broker
Kubernetes

It looks sophisticated.

But now a simple feature might require:

Multiple Services
Multiple Deployments
Network Communication
Service Authentication
Distributed Debugging
Event Coordination

We've created a distributed system before we actually had a distributed problem.

The architecture is now more complicated than the business.

A simpler starting point could be:

                 Modular Monolith
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Identity     Inventory      Sales
          │            │            │
          └────────────┼────────────┘
                       ▼
                   PostgreSQL

Everything can still deploy together.

But the boundaries remain explicit.

That's important.

Simple deployment does not have to mean chaotic architecture.

Modular Monolith vs Microservices

A modular monolith doesn't mean:

"We will never use microservices."

It means:

"We will introduce distribution when distribution solves a real problem."

The evolution can look like:

Modular Monolith
       │
       ▼
Identify Bottleneck
       │
       ▼
Find the Right Boundary
       │
       ▼
Extract One Capability
       │
       ▼
Independent Service

Suppose reporting becomes extremely expensive.

Instead of splitting everything:

Identity
Sales
Inventory
Billing
Reporting
Notifications

we might extract only reporting:

Main Application
│
├── Identity
├── Sales
├── Inventory
└── Billing

        +

Reporting Service

Now reporting can scale independently.

We didn't distribute the entire company.

We distributed the capability that actually needed it.

Architecture Should Have an Evolution Path

A system doesn't need its final architecture on day one.

It might begin as:

API
 │
 ▼
Application
 │
 ▼
PostgreSQL

Traffic increases:

API
 │
 ▼
Application
 │
 ├── PostgreSQL
 └── Redis

Background workloads grow:

API
 │
 ▼
Application
 │
 ├── PostgreSQL
 ├── Redis
 └── Workers

Asynchronous workflows become more complex:

API
 │
 ▼
Application
 │
 ├── PostgreSQL
 ├── Redis
 ├── Message Bus
 └── Workers

Eventually, perhaps one capability becomes independently scalable:

                 API Gateway
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        Sales      Inventory    Billing
          │           │           │
          └───────────┼───────────┘
                      ▼
                Event Platform

The important part isn't the final diagram.

It's the journey between the diagrams.

Good architecture is an evolution path, not a perfect diagram created on day one.

Five Questions Before Adding Complexity

Before introducing another architectural component, ask five questions.

1. What problem are we solving?

Don't begin with:

"Should we use Kafka?"

Begin with:

"What problem are we experiencing?"

2. Who should own this responsibility?

Ask:

"Which module should own this behavior?"

Ownership prevents responsibility from leaking everywhere.

3. Does this need to happen immediately?

Ask:

"Does the user need the result before the request finishes?"

If not, asynchronous processing may be appropriate.

4. What happens as the system grows?

Ask:

"Could this component become a bottleneck or coupling point?"

5. What does this component cost operationally?

Every new component creates work.

A new service can mean:

Deployment
Monitoring
Networking
Authentication
Debugging
Failure Handling
Documentation
Ownership

Architecture isn't free.

Every abstraction has a maintenance cost.

Every distributed component creates another possible failure boundary.

So good architects don't only ask:

"Can we add this?"

They ask:

"Do we actually need this?"

The Architecture I'd Start With

If I were starting a SaaS or ERP platform today, I wouldn't begin with a giant distributed architecture.

I'd start closer to:

                  Client Applications
                          │
                          ▼
                       API Layer
                          │
                          ▼
                  Modular Application
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
       Identity        Inventory         Sales
          │               │               │
          ├───────────────┼───────────────┤
          │               │               │
          ▼               ▼               ▼
       Billing        Purchasing      Reporting
                          │
                          ▼
                      PostgreSQL
                          │
                    ┌─────┴─────┐
                    ▼           ▼
                  Redis       Workers
                                │
                                ▼
                           Message Queue

Alongside it:

Authentication
Authorization
Tenant Isolation
Transactions
Structured Logging
Metrics
Tracing
CI/CD
Backups

And deliberately avoid introducing:

Microservices
Service Mesh
Kubernetes
Distributed Databases
Complex Event Platforms

until the product actually gives you a reason.

These technologies aren't bad.

The principle is simpler:

Complexity should be earned by the problem.

Production Architecture Checklist

Before calling an architecture production-ready, ask:

Business

Do we understand the business capabilities?
Are responsibilities clearly separated?
Do modules represent meaningful business boundaries?

Application

Is business logic separated from HTTP concerns?
Are use cases easy to identify?
Are dependencies understandable?
Can modules evolve independently where appropriate?

Data

Does the data model reflect business requirements?
Are important invariants protected?
Are transactions used correctly?
Are indexes based on real query patterns?
Is historical information preserved where necessary?

Security

Is authentication handled consistently?
Is authorization explicit?
Is tenant isolation enforced?
Are sensitive operations auditable?
Are secrets protected?

API

Are resources predictable?
Are responses consistent?
Are breaking changes controlled?
Is documentation available?
Is the API treated as a stable contract?

Performance

Is pagination implemented?
Are expensive queries optimized?
Is caching used where justified?
Can heavy work move to background processing?

Reliability

Are failures handled?
Can background jobs be retried safely?
Are critical operations idempotent where necessary?
Are backups available?
Can the system recover from dependency failures?

Observability

Can we trace requests?
Can we measure latency?
Can we identify errors?
Can we monitor database performance?
Can we understand queue and worker health?

Operations

Can we deploy safely?
Can we roll back?
Are secrets managed securely?
Are alerts configured?
Can engineers understand what's happening in production?

If you can't answer these questions, the architecture probably isn't finished.

The Architecture Mindset

After all of this, software architecture can sound complicated.

But the underlying process is surprisingly simple.

When designing a system, keep asking:

What is this system responsible for?

Then:

Who should own that responsibility?

Then:

How should that responsibility communicate with other parts of the system?

Then:

What data does it need?

Then:

What happens when something fails?

And finally:

What happens when the business becomes larger?

Those questions naturally lead to:

Business Requirements
        ↓
Business Capabilities
        ↓
Boundaries
        ↓
Modules
        ↓
Application Logic
        ↓
Data Architecture
        ↓
API Contracts
        ↓
Transactions
        ↓
Async Processing
        ↓
Security
        ↓
Observability
        ↓
Infrastructure
        ↓
Deployment

That's architecture.

Not the number of services.

Not the number of technologies.

Not how complicated the architecture diagram looks.

Beginner vs Senior Architecture Thinking

A beginner often asks:

"Which architecture should I use?"

A developer asks:

"How should I structure this project?"

A senior engineer asks:

"Where should this responsibility live?"

A CTO asks:

"How will this architecture affect the business six months from now?"

A strong architect eventually learns to ask all four.

Because the goal isn't to build the most sophisticated system.

The goal is to build something that is:

understandable today, maintainable tomorrow, and capable of evolving when the business changes.

Final Thoughts: Architecture Is a Journey 🧠

A business idea doesn't become a production system by adding more technologies.

It becomes a production system through a series of deliberate decisions.

First:

Understand the Business

Then:

Find the Responsibilities

Then:

Create Boundaries

Then:

Define Ownership

Then:

Protect the Data

Then:

Design the Contracts

Then:

Handle Failure

Then:

Measure the System

And only then:

Introduce Complexity When Necessary

That's the real progression.

Good architecture isn't about having more components.

It's about putting the right responsibility in the right place.

And perhaps the simplest way to remember it is:

Don't start with technology.

Start with the business.

Find the responsibilities.

Create the boundaries.

Define ownership.

Protect the data.

Design the interactions.

Plan for failure.

Measure the system.

Scale what actually needs scaling.

Then introduce complexity only when the problem earns it.

That's how a simple business idea becomes a production-ready software architecture.

Key Takeaways

Start architecture with business capabilities, not technologies.
Organize systems around responsibilities and ownership.
Use boundaries to prevent uncontrolled coupling.
Keep HTTP concerns separate from core business rules.
Treat the database as an architectural component.
Use transactions to protect operations that must succeed together.
Move appropriate workloads to asynchronous processing.
Separate authentication from authorization.
Treat tenant isolation as a security boundary.
Design APIs as stable contracts.
Add caching because a workload needs it, not because it's fashionable.
Build observability before production becomes difficult to debug.
Don't introduce microservices before you have a distributed problem.
Prefer a modular monolith when it provides enough structure for the current stage.
Design architecture as an evolution path, not a final diagram.
Every architectural component has an operational and maintenance cost.
Complexity should have a reason.

Before You Write Code, Ask Better Questions

Anik Sikder — Tue, 18 Aug 2026 19:21:22 +0000

Imagine you're building a SaaS platform.

Nothing unusual.

Just an employee management system.

The client says:

"We need employee management."

A developer says:

"Sure. I'll build employee CRUD."

So the implementation begins.

Employee
   ↓
Create
Read
Update
Delete

Simple.

Until the real requirements appear.

A few weeks later:

HR wants approval workflows.
Managers shouldn't see salary information.
Employees can belong to multiple departments.
Former employees must remain in historical reports.
The organization has multiple branches.
Some actions require approval.
Sensitive changes must be audited.
Another system needs an API.
Finance needs historical payroll data.

The developer didn't necessarily write bad code.

The problem happened before the code existed.

The team misunderstood the problem.

That's one of the most important lessons in software engineering:

Great software starts with great questions, not great code.

Requirement engineering is the process of turning:

Business Goals
      ↓
User Problems
      ↓
Requirements
      ↓
Business Rules
      ↓
Data
      ↓
Workflows
      ↓
Architecture
      ↓
Implementation
      ↓
Validation

When this chain breaks, even excellent developers can build the wrong system extremely well.

The Real Problem With Requirements

Consider this requirement:

"Managers can manage employees."

What does manage mean?

Can a manager:

create an employee?
edit personal information?
change salary?
change department?
deactivate an employee?
delete an employee?
invite an employee?
approve leave?
transfer an employee?
view payroll?
restore a former employee?

Every answer changes the software.

It can affect:

database structure
authorization
API design
service logic
UI workflows
audit requirements
testing
security
operational cost

The ambiguity existed before implementation.

The architecture simply exposes it later.

This is why requirements matter.

The earlier ambiguity is discovered, the cheaper it usually is to correct.

Requirements Are Not Features

One of the most important distinctions is between a business problem, a requirement, and a feature.

A client says:

"We need a dashboard."

That's a proposed solution.

Ask:

"Why?"

Maybe the real problem is:

"Finance managers cannot quickly identify overdue customer payments."

Now the requirement becomes:

"Authorized finance users must be able to identify overdue customer balances and prioritize collection actions."

The eventual feature could be:

Payment Aging Dashboard
        +
Overdue Invoice Table
        +
Filtering
        +
Notifications
        +
Collection Workflow

The feature came after understanding the requirement.

This distinction matters because stakeholders often describe what they think should be built.

Engineers need to discover why it needs to exist.

A useful mental model is:

Business Problem
      ↓
Desired Outcome
      ↓
Requirement
      ↓
Feature
      ↓
Implementation

Don't start at the bottom.

The Three Questions Behind Every Requirement

When someone gives you a requirement, don't immediately ask:

"How do we build this?"

Ask three questions first.

1. Why?

What business problem are we solving?

2. What?

What capability does the system need?

3. Under What Conditions?

What rules, permissions, constraints, and exceptions apply?

Consider:

"Users should be able to transfer organization ownership."

Why?

The current owner is leaving the company.

What?

Ownership must be transferred to another eligible member.

Under what conditions?

Perhaps:

the target must belong to the organization
the owner cannot transfer ownership to themselves
only one active transfer request can exist
the target must accept the request
the request expires after 72 hours
the operation must be transactional
the transfer must be audited
notifications must be sent

Now we have something engineers can actually design.

The original sentence was only the beginning.

How Engineers Discover Requirements

Requirements rarely arrive in a perfectly structured document.

They are usually discovered through conversations, observation, existing systems, documents, and prototypes.

Ask People to Explain the Workflow

A weak interview asks:

"What features do you want?"

A better question is:

"Walk me through what happens today."

Suppose you're building an expense management system.

Don't only ask:

"Do you need expense approval?"

Ask:

"What happens when an employee submits a $500 expense?"

You may discover:

Employee submits expense
        ↓
Manager reviews
        ↓
Large expenses require additional approval
        ↓
Finance validates receipt
        ↓
Approved expense goes to payroll
        ↓
Employee is reimbursed
        ↓
Audit history is preserved

The requirement wasn't simply:

Expense → Approved

It was a business workflow.

Observe the Work

Users sometimes cannot explain everything they do because much of their workflow has become habitual.

An accountant might say:

"I just reconcile the transaction."

But observation might reveal:

Export bank statement
        ↓
Normalize dates
        ↓
Match transaction IDs
        ↓
Search invoice numbers
        ↓
Compare amounts
        ↓
Resolve discrepancies
        ↓
Send exceptions to finance

The real requirement may be:

"Reduce manual reconciliation effort while preserving traceable exception handling."

Observation exposes implicit requirements.

Bring Stakeholders Together

Different departments often have different expectations.

HR might say:

"Managers should edit employee information."

Finance might say:

"Managers shouldn't edit salary information."

Security might say:

"Sensitive changes must be audited."

The requirement becomes more precise:

Managers
   ↓
Can edit permitted employee data
   ↓
Compensation changes require additional authorization
   ↓
Sensitive changes are audited

Workshops are useful because contradictions become visible before implementation.

Study Existing Systems

If you're replacing an old system, don't assume it has nothing useful to teach you.

Look at:

existing workflows
spreadsheets
reports
APIs
database schemas
approval forms
policies
integrations
historical behavior

Existing software often contains years of accumulated business rules.

Sometimes the best requirements are hiding inside:

what the current system already does.

Use Prototypes

People often discover missing requirements when they see something concrete.

Imagine showing:

Expense #1042

Employee: John
Amount: $1,450
Category: Travel

[Approve] [Reject] [Request Changes]

The stakeholder says:

"Managers shouldn't approve anything above $1,000."

Excellent.

The prototype just revealed a business rule.

Prototypes aren't only design tools.

They're requirement discovery tools.

Ask About Failure, Not Just Success

Most people naturally explain the happy path.

For example:

"A customer places an order and we ship it."

But production systems need answers to:

What if payment fails?
What if payment succeeds but order creation fails?
What if inventory disappears?
What if the customer cancels?
What if the address is invalid?
What if the order is partially shipped?
What if the payment provider sends the same webhook twice?
What if the external service is unavailable?

The happy path is usually easy.

The exceptions define the real system.

This is why one of the most valuable questions in requirement engineering is:

"What happens when things go wrong?"

And an even stronger one is:

"What must never happen?"

For example:

Payments
→ Customer must never be charged twice.

IAM
→ A user must never access another tenant's data.

Payroll
→ An employee must never be paid incorrectly.

Inventory
→ Stock must not become negative unless explicitly allowed.

Ownership
→ Two people must never become owners simultaneously.

These statements reveal business invariants.

And invariants are extremely valuable architectural information.

Functional vs Non-Functional Requirements

Another important distinction is between functional and non-functional requirements.

Functional Requirements

These describe what the system does.

Examples:

Users can create invoices.
Managers can approve expenses.
Employees can submit leave requests.
Administrators can deactivate users.
Customers can reset passwords.

Non-Functional Requirements

These describe how the system should behave or what constraints it must satisfy.

Examples:

APIs should meet a defined latency target.
Sensitive data must be encrypted.
Protected resources require authentication.
The system must support a defined number of concurrent users.
Audit records must be retained for a specified period.
The service must meet an agreed availability target.

A simple mental model:

Functional
=
Capability

Non-Functional
=
Quality + Constraint + Operational Expectation

Both can change architecture.

Imagine:

System A
50 internal users
Single region
Business hours

versus:

System B
5 million users
Multiple regions
24/7 operation
High availability

Both could have:

"Users can create profiles."

But System B may require:

caching
replication
partitioning
queues
rate limiting
CDN
horizontal scaling
observability
disaster recovery

The feature didn't change.

The constraints did.

Requirements Shape Architecture

A useful mental model is:

Business Goal
      ↓
Requirements
      ↓
Constraints
      ↓
Architecture
      ↓
Implementation

Consider:

"Every financial change must be traceable."

That requirement might influence:

database design
transaction boundaries
audit tables
event logging
authorization
API design
service boundaries
data retention

Another example:

"A payment must only be completed once."

That can lead to:

idempotency keys
unique constraints
event IDs
transaction boundaries
webhook verification
retry handling

Another:

"An organization can only access its own data."

That can influence:

authentication
authorization
database queries
service-layer rules
background jobs
caching
testing

This is why requirement engineering is not separate from architecture.

Requirements are constraints on architecture.

Requirements Create Domain Models

Consider:

"An organization has members with different roles."

Simple?

Not for long.

You need to ask:

Is a role global or organization-specific?
Can one member have multiple roles?
Who can assign roles?
Can roles be removed?
Are permissions inherited?
Can roles change over time?
Should role changes be audited?

You may eventually discover:

Organization
      ↓
Membership
      ↓
Role
      ↓
Permission

The requirement didn't simply create a UI.

It created a domain model.

The same thing happens with:

orders
payments
invoices
employees
subscriptions
ownership
verification
inventory

A requirement often contains the seeds of the domain model.

Current State Isn't Always Enough

Suppose:

"John is a manager."

That's current state.

But six months later someone asks:

"Was John a manager when he approved expense #10042?"

Now you need historical state.

This is why enterprise systems often need to answer:

"What was true when this event happened?"

That can affect:

audit design
financial records
reporting
authorization history
compliance
event storage

Consider an employee who leaves the company.

You might not want:

DELETE Employee

Instead:

Employee.status = inactive

Why?

Because historical payroll, expenses, approvals, and audit records may still depend on that employee.

This leads to an important principle:

Business history is often more important than current state.

A Ticket Is Not a Requirement

A ticket says:

"Add employee deletion."

Don't immediately write:

def delete_employee():
    ...

Ask:

"What does delete mean in this business?"

It could mean:

Hard Delete

The record disappears.

Soft Delete

The record remains but is marked inactive.

Deactivation

The employee loses access but historical records remain.

Archival

The employee moves into a historical state.

Termination

A business event occurs and triggers downstream workflows.

These are completely different behaviors.

The ticket gave you a verb.

Your job is to discover the domain meaning behind the verb.

User Stories Are Useful — But Not Enough

Consider:

As a manager, I want to approve an expense so that employees can be reimbursed.

That's useful.

But you still need to know:

Preconditions

Expense exists
Expense is submitted
Manager has permission

Rules

Manager cannot approve their own expense
Large expenses require additional approval

State Transition

Submitted → Approved

Failure Cases

Already approved
Already rejected
Permission removed

Audit

Who?
When?
What changed?

A user story describes intent.

It doesn't necessarily describe the complete system behavior.

Think in State Machines

Many business processes are really state machines.

For example:

Draft
  ↓
Submitted
  ↓
Under Review
  ↓
Approved
  ↓
Completed

Not every transition is valid.

For example:

Draft → Completed

may be forbidden.

And:

Approved → Rejected

may be impossible.

Once you recognize the state machine, the requirement becomes much clearer.

You can define:

State
Transition
Actor
Permission
Condition
Side Effect

This model is useful for:

orders
payments
invoices
expenses
leave requests
ownership transfers
verification
onboarding
procurement
support tickets

A workflow isn't just a sequence of screens.

It's a set of valid state transitions.

Requirements Can Define Transactions

Consider ownership transfer:

Validate target
      ↓
Accept request
      ↓
Remove old owner
      ↓
Assign new owner
      ↓
Create audit event

What happens if the old owner is removed but the new owner isn't assigned?

The organization could become invalid.

So the requirement may be:

"Ownership transfer must happen atomically."

That's not merely a coding preference.

It's a business integrity requirement.

It can lead directly to:

database transactions
consistency rules
locking
failure handling
service boundaries

Business requirements can become database requirements.

Requirements Can Define Security Boundaries

Consider:

"Organizations can manage their own users."

That sentence contains a security boundary.

The system must guarantee:

Organization A
      ↓
Authorized Users

cannot access:

Organization B
      ↓
Private Users

This affects more than the UI.

It affects:

queries
services
APIs
authentication
authorization
background jobs
caching
logging
tests

For multi-tenant systems, tenant isolation isn't just an implementation detail.

It's a requirement.

Requirements Should Be Testable

Consider:

"The application should be fast."

Everyone agrees.

But how do you test it?

A better requirement might be:

"95% of API requests under the expected workload should complete within 300ms."

Now it is measurable.

The same principle applies to business behavior.

Instead of:

"Managers can approve expenses."

Use something closer to:

Given an authorized manager and a submitted expense, when the manager approves it, the expense transitions to Approved, the approver and timestamp are recorded, and an audit event is created.

Now:

the developer knows what to build
QA knows what to test
the buyer knows what to expect

That's the value of acceptance criteria.

Requirement Validation

After discovering requirements, validate them.

Ask:

Is it correct?

Does it represent the real business need?

Is it complete?

Are important cases missing?

Is it consistent?

Does it conflict with another requirement?

Is it feasible?

Can the system realistically satisfy it?

Is it testable?

Can we objectively determine whether it works?

Is it traceable?

Can we connect it to the business goal, implementation, and tests?

A requirement such as:

"The system should be secure."

is too broad.

Break it into observable guarantees:

Protected endpoints require authentication.
Users cannot access another tenant's resources.
Sensitive actions are audited.
Reset tokens expire.
Authorization is enforced server-side.
Payment confirmations are verified server-side.

Now the team can actually build and test against it.

Ambiguity Is Expensive

Imagine a requirement misunderstanding happens during week one.

The team discovers it before implementation.

Maybe the solution is a conversation and a revised workflow.

Now imagine the same misunderstanding is discovered after production.

You may need:

database migrations
API changes
frontend changes
data migration
regression testing
security review
deployment changes
customer communication

The exact cost varies.

But the principle is consistent:

The later ambiguity is discovered, the more expensive it becomes.

This is why requirement engineering isn't bureaucracy.

It's risk management.

Estimation Starts With Understanding

Developers are often asked:

"How long will this take?"

But estimating an ambiguous requirement is mostly guessing.

Compare:

Requirement A

"Build reporting."

Requirement B

"Finance managers need monthly revenue reports filtered by organization, branch, customer, product category, payment status, and date range. Reports must support CSV export and preserve historical transaction values."

Requirement B is much easier to estimate.

Not because it's necessarily smaller.

Because uncertainty has been reduced.

Better requirements don't make work magically disappear.

They make the work visible.

Prioritization Is Also Risk Management

Not every requirement deserves the same priority.

A practical model:

Must Have

The system cannot provide its core value without it.

Should Have

Important, but not essential for the first release.

Could Have

Useful, but optional.

Won't Have Now

Explicitly outside the current scope.

But business priority isn't the only consideration.

Technical risk matters too.

Consider:

"Integrate with the bank's payment system."

It sounds like one feature.

But it may involve:

authentication
webhook verification
retries
idempotency
reconciliation
settlement
refunds
duplicate events
failure recovery

That requirement may deserve early investigation even if it isn't the most visible feature.

A useful prioritization model considers:

Business Value
+
Technical Risk
+
Dependencies
+
Cost
+
Security Impact

Requirement Changes Need Impact Analysis

Requirements don't stop changing when development begins.

Businesses change.

Customers change.

Regulations change.

New information appears.

Suppose the buyer says:

"Managers should also be able to approve payroll."

Don't simply add a permission.

Ask:

"What else changes?"

Potentially:

Authorization
     ↓
Workflow
     ↓
Payroll Data Access
     ↓
Audit
     ↓
Notifications
     ↓
Reporting
     ↓
Compliance
     ↓
UI
     ↓
Tests

This is why:

"It's just a small change."

can sometimes become a very expensive sentence.

A requirement change can have architectural consequences.

What Great Engineers Actually Do

Great engineers don't just translate tickets into code.

They ask:

Is this the real problem?

What assumption are we making?

What happens when it fails?

Who is allowed to do this?

What happens to historical data?

What if the request is duplicated?

What if two users act simultaneously?

What if an external service is unavailable?

What happens when the business grows?

What must never happen?

These questions reveal the system's true boundaries.

That's engineering judgment.

The Difference Between Working Software and Correct Software

A system can technically work.

The API returns 200.

The UI looks beautiful.

The database is normalized.

The tests pass.

And the product can still be wrong.

Why?

Because:

Implementation correctness does not guarantee business correctness.

You can implement the specification perfectly and still fail if the specification misunderstood the business.

That's why one of the most important questions isn't:

"Did we build it correctly?"

It's:

"Did we define the right thing correctly?"

The Real Engineering Loop

A mature development process looks more like:

Understand
   ↓
Question
   ↓
Model
   ↓
Validate
   ↓
Design
   ↓
Implement
   ↓
Test
   ↓
Observe
   ↓
Learn
   ↓
Refine

Not:

Ticket
  ↓
Code
  ↓
Deploy

The second approach may feel faster.

The first approach is much more likely to produce software that survives real-world complexity.

For Buyers: Ask Better Questions

If you're buying serious software, don't ask only:

"How quickly can you build this?"

Ask:

"How will you make sure you're building the right thing?"

Before development begins, you should expect discussion around:

business goals
workflows
users
roles
permissions
data
integrations
exceptions
performance
security
scalability
reporting
operational requirements

A developer who asks difficult questions isn't necessarily slowing your project down.

They may be preventing expensive mistakes.

For Developers: Your Value Isn't Just Code

Frameworks change.

Libraries change.

Cloud services change.

Programming languages evolve.

But the ability to understand ambiguous problems remains valuable.

A developer who can:

discover requirements
challenge assumptions
model domains
identify invariants
understand workflows
design secure boundaries
reason about failure
preserve business history
evaluate tradeoffs

is solving a much bigger problem than implementing endpoints.

Your value isn't simply:

How fast can I write code?

It's:

How accurately can I turn
an ambiguous business problem
into a reliable system?

That's a much harder skill.

And a much more valuable one.

The Question Worth Remembering

Before writing the first line of code, ask:

"What do we need to know before we can confidently build this?"

That question may expose:

an unclear business rule
an undefined permission boundary
missing historical requirements
an unknown failure scenario
an architectural constraint
a security risk

And finding those things early is usually far cheaper than discovering them after production.

Because in software engineering:

A fast developer can build the wrong thing quickly.

A strong engineer makes sure the right thing is being built in the first place.

Key Takeaways

Great software starts with understanding the problem, not choosing a framework.
Requirements are not the same as features.
Ask why, what, and under what conditions.
Discover both the happy path and failure paths.
Functional requirements define capabilities.
Non-functional requirements define quality and constraints.
Requirements can directly shape architecture.
Historical data can be as important as current state.
Authorization and tenant isolation are requirement-level concerns.
Business invariants should be explicitly identified.
State transitions reveal hidden complexity.
Transactions and idempotency can emerge directly from business requirements.
Acceptance criteria turn vague expectations into observable behavior.
Requirement changes should trigger impact analysis.
Great engineers don't just implement tickets—they challenge assumptions.
Better questions reduce ambiguity, rework, cost, and architectural surprises.
Thinking is part of engineering.

Why API Architecture Is a Business Decision, Not a Technical One

Anik Sikder — Sun, 16 Aug 2026 20:07:45 +0000

Modern software products are API-driven businesses.

Whether building SaaS platforms, ERP systems, marketplaces, mobile applications, or internal enterprise software, nearly every business operation eventually becomes an API request.

Customers place orders through APIs.

Mobile applications consume APIs.

Partners integrate through APIs.

Automation workflows execute through APIs.

Future products are built on top of APIs.

As a result, API architecture is no longer just a backend implementation detail. It becomes one of the most important strategic decisions in software systems because it directly influences growth, scalability, operational efficiency, product velocity, and long-term maintenance costs.

The quality of an organization's API architecture often determines whether the platform becomes easier to evolve over time or increasingly difficult to change.

Executive Summary

Most discussions about APIs focus on endpoints, authentication mechanisms, request formats, or framework choices.

These topics are important.

However, they miss the larger picture.

API architecture defines how business capabilities are exposed, consumed, reused, secured, and evolved.

A well-designed API architecture creates:

Faster product delivery
Easier integrations
Better customer experience
Lower operational costs
Improved scalability
Stronger security
Better developer experience
Greater long-term flexibility

A poorly designed API architecture creates:

Feature bottlenecks
Integration friction
Engineering complexity
Repeated implementations
Platform inconsistency
Expensive rewrites
Operational inefficiencies

The difference between a software product and a software platform is often the quality of its API architecture.

The Real Problem

Most systems do not fail because of insufficient features.

They fail because the architecture cannot support growth.

Consider a business platform that contains:

User Management
Products
Inventory
Orders
Billing
Reporting
Notifications
Automation

Initially, development feels simple.

A frontend sends requests.

The backend processes them.

The database stores data.

Everything appears manageable.

Over time, however, new requirements emerge:

Mobile applications
Third-party integrations
Internal automation
Public APIs
Partner portals
Analytics systems
External marketplaces

Without a structured API architecture, complexity begins growing faster than business value.

Common symptoms appear:

Business logic duplication
Inconsistent interfaces
Difficult integrations
Expensive feature development
Slower releases
Rising maintenance costs

Eventually, the platform becomes harder to maintain than the business itself.

At this point, architecture becomes a business constraint.

Understanding APIs as Business Capabilities

Many systems are designed around screens.

Mature systems are designed around capabilities.

This distinction is critical.

Screen-oriented thinking often produces APIs like:

POST /create-product
GET /get-user-orders
POST /submit-payment

Capability-oriented thinking produces APIs like:

POST /products
GET /orders
POST /payments

The difference appears small.

The impact is enormous.

Capabilities can be reused.

Screens cannot.

A capability-oriented API allows multiple consumers to share the same business logic:

                Products API
                       │
      ┌────────────────┼────────────────┐
      ▼                ▼                ▼
   Web App        Mobile App      Partner API
      ▼                ▼                ▼
      └──────────── Same Capability ───┘

Instead of rebuilding functionality repeatedly, the system exposes reusable business capabilities that can support current and future products.

This transforms APIs from implementation details into long-term business assets.

The Cost of Architectural Debt

Most technical debt is visible.

API debt often remains hidden until scale arrives.

Stage 1: Initial Product

Frontend
    │
    ▼
Backend
    │
    ▼
Database

Simple.

Fast.

Easy to understand.

Stage 2: Additional Clients

Web
 │
 ▼

Backend
 │
 ▼
Database

Mobile
 │
 ▼
Backend

API quality now matters.

Multiple consumers depend on the same contract.

Stage 3: Integrations

Web App
Mobile App
Partner Systems
Internal Tools
Automation
       │
       ▼
    Backend
       │
       ▼
    Database

Inconsistencies become expensive.

Every integration requires additional effort.

Every change introduces risk.

Stage 4: Platform Scale

Customers
Partners
Vendors
Automation
Analytics
Future Products
        │
        ▼
     Platform

The architecture now influences every business initiative.

The cost of poor decisions compounds.

The value of good decisions compounds as well.

Architecture as an Execution Layer

Every business strategy eventually becomes software behavior.

Every software behavior eventually becomes an API interaction.

This makes APIs the execution layer between business goals and technical systems.

Business Objectives
         │
         ▼
Business Capabilities
         │
         ▼
API Contracts
         │
         ▼
Application Services
         │
         ▼
Infrastructure

When API architecture is designed well, new initiatives move quickly through this chain.

When API architecture is designed poorly, every initiative becomes slower, more expensive, and riskier.

High-Level Architecture Blueprint

A scalable API platform should separate concerns into distinct layers.

                    ┌─────────────────────┐
                    │    Client Layer     │
                    │ Web, Mobile, APIs   │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │     API Gateway     │
                    └──────────┬──────────┘
                               │
      ┌────────────────────────┼────────────────────────┐
      ▼                        ▼                        ▼

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│Authentication│      │ Authorization│      │ Rate Limiting│
└──────┬───────┘      └──────┬───────┘      └──────┬───────┘
       └─────────────────────┼─────────────────────┘
                             ▼

                 ┌─────────────────────────┐
                 │      Service Layer      │
                 │ Business Capabilities   │
                 └───────────┬─────────────┘
                             │
       ┌─────────────────────┼─────────────────────┐
       ▼                     ▼                     ▼

 ┌────────────┐      ┌────────────┐      ┌────────────┐
 │ PostgreSQL │      │ Redis      │      │ Message Bus│
 │ Source     │      │ Cache      │      │ Async Work │
 │ of Truth   │      │ Layer      │      │ Processing │
 └────────────┘      └────────────┘      └────────────┘

Each layer exists for a specific reason.

Authentication establishes identity.

Authorization enforces business rules.

Rate limiting protects resources.

Services execute business capabilities.

Databases persist information.

Caches improve performance.

Message queues enable scale.

The architecture remains understandable because responsibilities remain separated.

The Request Lifecycle

Every request should follow a predictable journey.

Client Request
      │
      ▼
API Gateway
      │
      ▼
Authentication
      │
      ▼
Authorization
      │
      ▼
Input Validation
      │
      ▼
Business Logic
      │
      ▼
Data Persistence
      │
      ▼
Response

A consistent lifecycle improves:

Security
Testing
Debugging
Monitoring
Maintainability
Reliability

Predictability becomes increasingly valuable as systems grow.

The Four Architectural Decisions That Shape Growth

1. API-First vs Interface-First

Many systems are designed around screens.

Scalable systems are designed around capabilities.

Interface-First

Screen
   │
   ▼
Backend Logic

API-First

Business Capability
         │
         ▼
         API
         │
 ┌───────┼────────┐
 ▼       ▼        ▼

Web   Mobile   Partner

The API-first approach creates reusable building blocks rather than isolated implementations.

2. Synchronous vs Event-Driven Processing

Not every operation should complete during a request.

Synchronous

Request
   │
   ▼
Process
   │
   ▼
Response

Simple.

But limited.

Event-Driven

Request
   │
   ▼
Queue Message
   │
   ▼
Worker
   │
   ▼
Background Processing

Ideal for:

Notifications
Emails
Reporting
Exports
Integrations
Audit Logs

This approach improves responsiveness while supporting growth.

3. Modular Monolith vs Distributed Systems

One of the most common mistakes is introducing complexity too early.

A well-structured modular monolith often provides:

Faster development
Easier debugging
Lower operational costs
Simpler deployments
Better maintainability

Application
│
├── Users Module
├── Orders Module
├── Inventory Module
├── Billing Module
└── Reporting Module

Strong internal boundaries usually provide more value than premature distribution.

4. APIs as Products

Many systems expose APIs.

Few treat them as products.

A product-quality API requires:

Consistency
Documentation
Reliability
Versioning
Security
Developer Experience

The API itself becomes part of the customer experience.

Versioning Strategy

Change is inevitable.

Breaking consumers is optional.

A versioning strategy allows systems to evolve safely.

/api/v1/products

/api/v2/products

Benefits include:

Backward compatibility
Safer deployments
Controlled migrations
Reduced disruption

Versioning is not merely a technical mechanism.

It is an operational stability strategy.

Authentication and Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

These concerns should remain separate.

A common authorization model is RBAC:

User
 │
 ▼
Role
 │
 ▼
Permissions

Example permissions:

invoice.create
invoice.view
inventory.adjust
user.invite

This structure scales naturally as systems become more complex.

Scalability Beyond Infrastructure

Scalability is often misunderstood.

Adding servers is infrastructure scaling.

Reducing architectural friction is system scaling.

Important scalability mechanisms include:

Pagination
Filtering
Search
Caching
Background processing
Rate limiting

For example:

GET /orders?page=1&page_size=50

is significantly more scalable than returning hundreds of thousands of records in a single response.

Architecture determines efficiency long before infrastructure becomes a problem.

Observability as a Platform Requirement

Visibility is not optional.

Without observability, systems become difficult to understand and improve.

Three pillars are essential:

Logs
Metrics
Traces

Together they answer:

What happened?
How often?
Where did it happen?
Why did it happen?

An observable platform is easier to operate, maintain, and evolve.

Common Architectural Mistakes

Breaking Existing Contracts

Changing APIs without versioning creates instability.

Business Logic Inside Controllers

Bad:

Controller = Business Logic

Better:

Controller
    │
    ▼
Service Layer
    │
    ▼
Repository

Returning Excessive Data

Large responses increase:

Memory consumption
Query costs
Response times

Use pagination.

Missing Rate Limiting

Without protection, systems become vulnerable to:

Abuse
Traffic spikes
Resource exhaustion
Cost increases

Rate limiting should be considered a foundational capability.

Architecture Evolution Roadmap

Most successful platforms evolve gradually.

Simple CRUD APIs
         │
         ▼
Authentication
         │
         ▼
Authorization
         │
         ▼
Caching
         │
         ▼
Background Jobs
         │
         ▼
API Gateway
         │
         ▼
Event-Driven Architecture

The goal is not maximum complexity.

The goal is appropriate complexity.

Systems should evolve in response to real requirements rather than assumptions.

Conclusion

API architecture is not about endpoints.

It is about designing how capabilities are exposed, consumed, secured, reused, and evolved.

A well-designed API architecture creates leverage.

It allows multiple products, integrations, automations, and future initiatives to operate on a shared foundation.

The result is:

Faster development
Better scalability
Easier integrations
Lower operational costs
Stronger security
Improved maintainability
Better developer experience

The most valuable APIs are not simply interfaces.

They are the contracts that define how an entire software platform operates, grows, and adapts over time.

That is why API architecture is not merely a technical concern.

It is a fundamental platform design decision with long-term business consequences.

DNS Propagation Explained: Why DNS Changes Take Time and What Actually Happens Behind the Scenes

Anik Sikder — Thu, 13 Aug 2026 16:30:00 +0000

In the previous article, we explored:

How DNS works
How DNS records power websites, email systems, and cloud infrastructure

At this point, a natural question emerges:

If DNS changes are just records stored on a server, why don’t updates happen instantly?

Imagine moving a website to a new server.

You update the DNS record.

You refresh your browser.

Nothing changes.

An hour later, some users see the new website.

Others still see the old one.

A colleague in another country sees something completely different.

Monitoring tools report mixed results.

Suddenly everyone starts asking:

Has DNS propagated yet?

This is one of the most misunderstood concepts in networking.

In reality, DNS propagation is not magic.

It is not a global synchronization event.

And contrary to popular belief, DNS records do not slowly travel across the internet.

What actually happens is far more interesting.

Understanding DNS propagation requires understanding three critical concepts:

DNS Cache
DNS TTL
Recursive Resolvers

Once those concepts click, DNS behavior becomes predictable instead of mysterious.

The Biggest Misconception About DNS Propagation

Most explanations describe DNS propagation like this:

code

DNS Change
      ↓
Internet Updates Everywhere
      ↓
Propagation Complete

This sounds reasonable.

Unfortunately, it isn’t how DNS works.

There is no global “update internet” button.

There is no mechanism that pushes your DNS change to every network on Earth.

The internet doesn’t work that way.

A more accurate model looks like this:

code

DNS Change
      ↓
Old Answers Expire
      ↓
Resolvers Ask Again
      ↓
New Answers Are Cached

This distinction is important.

Because understanding it helps explain nearly every DNS propagation issue.

What DNS Propagation Actually Means

When people say:

DNS propagation is taking time

What they usually mean is:

Some systems are still using cached DNS information.

That’s it.

Propagation is largely a caching problem.

Not a distribution problem.

The internet already knows where your DNS records live.

The challenge is that millions of systems may still trust older answers.

Understanding DNS Cache

DNS would be incredibly inefficient without caching.

Imagine every website visit requiring:

Contact Root Servers
Contact TLD Servers
Contact Authoritative Nameservers
Retrieve DNS Records

For every request.

For every user.

For every page load.

The internet would be overwhelmed.

Instead, DNS uses caching extensively.

Where DNS Is Cached

Most people assume DNS is cached in only one location.

In reality, DNS is cached everywhere.

Browser Cache

Your browser remembers previous DNS lookups.

For example:

code

chrome
firefox
safari
edge

all maintain their own caches.

Operating System Cache

The operating system also stores DNS responses.

Examples:

code

Windows
Linux
macOS
Android
iOS

all implement DNS caching.

Router Cache

Many routers cache DNS responses.

This includes:

Home routers
Office routers
Enterprise firewalls

ISP Cache

Internet Service Providers often cache DNS records.

Recursive Resolver Cache

Resolvers such as:

code

Google DNS
8.8.8.8

Cloudflare DNS
1.1.1.1

maintain massive DNS caches.

This is where most DNS propagation delays originate.

Why DNS Caching Exists

Caching solves several major problems.

Faster Performance

Without caching:

Every DNS lookup would require multiple network requests.

Caching dramatically reduces lookup times.

Reduced Infrastructure Load

DNS infrastructure handles billions of requests daily.

Caching prevents unnecessary traffic.

Improved Reliability

Cached answers remain available even when upstream systems experience temporary issues.

Caching is one of the reasons DNS scales globally.

DNS TTL Explained

TTL stands for:

Time To Live

TTL determines how long a DNS response can remain cached before it must be refreshed.

Example:

code

example.com. 3600 IN A 203.0.113.10

Here:

code

3600 seconds

equals:

code

1 hour

This means:

A resolver may reuse this answer for one hour before requesting a fresh copy.

TTL Is the Heart of DNS Propagation

When people ask:

Why hasn’t my DNS update appeared yet?

The answer is often:

The previous TTL has not expired.

Resolvers continue trusting old information until the cache expires.

Only then do they ask for new information.

A Practical Example

Imagine a website currently points to:

code

203.0.113.10

The DNS record has:

code

TTL = 86400

which equals:

code

24 hours

At 9:00 AM you update the record:

code

203.0.113.50

What happens?

Many resolvers continue using:

code

203.0.113.10

until their cached record expires.

The new server may not become visible everywhere for many hours.

This is normal.

Why Some People See Changes Before Others

A common source of confusion:

Two people check the same domain.

One sees the new website.

The other sees the old website.

Why?

Because they are not necessarily using the same resolver.

Example:

code

User A → Cloudflare DNS
User B → ISP Resolver

If one cache expires earlier than another, different answers appear temporarily.

This creates the illusion that DNS propagation is inconsistent.

In reality, different caches are simply operating on different timelines.

The Lifecycle of a DNS Change

A DNS update generally follows this pattern:

Step 1

A record changes on the authoritative nameserver.

Step 2

Existing caches continue using older answers.

Step 3

TTL expires.

Step 4

Resolvers request fresh information.

Step 5

New answers are cached.

Step 6

Traffic gradually shifts to the new destination.

This process is what people call:

DNS Propagation

Why Lowering TTL Before Migrations Matters

Experienced infrastructure teams rarely make DNS changes without preparation.

Suppose a website migration is scheduled for Friday.

The existing record has:

code

TTL = 86400

One day before the migration:

code

TTL = 300

is configured.

This reduces cache duration to:

code

5 minutes

Now when the migration occurs, resolvers refresh much faster.

The transition becomes significantly smoother.

The Most Common DNS Migration Mistake

A surprisingly common scenario:

Monday

TTL remains:

code

Tuesday

Migration begins.

Tuesday Afternoon

Traffic appears inconsistent.

Tuesday Evening

People assume DNS is broken.

In reality:

The TTL strategy was never planned.

The migration itself may be perfectly correct.

DNS Propagation and Website Launches

Launching a new website often involves:

DNS updates
SSL certificates
CDN configuration
Email setup
Search engine verification

DNS propagation affects all of them.

Many launch-day issues are actually cache-related issues.

Understanding propagation helps avoid unnecessary panic.

DNS Propagation and Email Systems

Email migrations are especially sensitive.

A website outage is obvious.

Email failures often aren’t.

If MX records change:

code

example.com IN MX 10 mail.old-provider.com

becomes:

code

example.com IN MX 10 mail.new-provider.com

different mail servers may temporarily use different routes.

Proper TTL planning becomes critical.

DNS Propagation and Search Visibility

Search engines rely on DNS continuously.

They must:

Crawl websites
Verify ownership
Access resources

Poorly planned DNS changes can temporarily impact accessibility.

This doesn’t automatically harm rankings.

However, prolonged outages or misconfigured migrations can create crawl issues.

Infrastructure reliability remains an important foundation for search visibility.

DNS Propagation and GEO

As AI-powered discovery systems become more common, reliable infrastructure becomes increasingly important.

Large language models, answer engines, and AI search platforms must access content consistently.

DNS instability can affect:

Content accessibility
Crawling consistency
Service reliability

Strong DNS practices contribute to long-term discoverability.

How to Check DNS Propagation

Several approaches exist.

Using dig

code

dig example.com

Query Specific Resolvers

code

dig @8.8.8.8 example.com

code

dig @1.1.1.1 example.com

Comparing results helps identify cache differences.

Online DNS Checkers

DNS propagation tools query multiple locations worldwide.

These tools provide a useful snapshot of resolver behavior across regions.

Does DNS Propagation Really Take 48 Hours?

One of the oldest myths in networking is:

DNS propagation takes 24 to 48 hours.

Historically, this was often true.

Modern DNS infrastructure behaves differently.

Most changes appear much faster.

The real answer depends on:

TTL values
Resolver behavior
Cache state
Network policies

Many updates become visible within minutes.

Others may take significantly longer.

The key variable is caching.

Not geography.

Not distance.

Not internet speed.

Caching.

Common DNS Propagation Myths

Myth #1

DNS changes spread slowly around the world.

Reality:

Resolvers refresh cached information when TTL expires.

Myth #2

DNS propagation always takes 48 hours.

Reality:

Many changes appear within minutes.

Myth #3

DNS propagation can be forced globally.

Reality:

You cannot instantly clear every cache on the internet.

Myth #4

DNS propagation means DNS is broken.

Reality:

Propagation is usually normal DNS behavior.

Best Practices for DNS Changes

Reduce TTL Before Major Changes

Prepare caches before migrations.

Verify Records Before Updating

Prevent avoidable mistakes.

Monitor Multiple Resolvers

Avoid relying on a single DNS source.

Plan Email Migrations Carefully

Email outages are often harder to detect than website outages.

Understand Cache Behavior

Most propagation issues are cache issues.

Key Takeaways

DNS propagation is primarily a caching phenomenon.
DNS records do not physically spread across the internet.
DNS TTL controls cache lifetime.
DNS cache exists in browsers, operating systems, routers, ISPs, and recursive resolvers.
Different users may see different DNS answers during propagation.
Lower TTL values can simplify migrations.
Most propagation issues are cache-related rather than DNS-related.
Understanding propagation reduces downtime, confusion, and migration risk.
Reliable DNS practices support website availability, email delivery, and long-term discoverability.

DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV Records in Modern Internet Infrastructure

Anik Sikder — Tue, 11 Aug 2026 16:30:00 +0000

In the previous article, we explored how DNS translates human-friendly domain names into machine-friendly IP addresses and how a request travels through recursive resolvers, root servers, TLD servers, and authoritative nameservers before finally reaching a destination.

That journey answers how DNS works.

This article answers a different question:

What information is DNS actually returning?

When a DNS resolver contacts an authoritative nameserver, it isn’t simply asking for an IP address.

It is asking for a specific record.

Those records determine:

Where websites live
Where email should be delivered
Which servers are authoritative
How domains are verified
How email is authenticated
How cloud services are discovered
How SaaS platforms connect custom domains
How modern internet infrastructure operates

In other words:

DNS resolution is the process.

DNS records are the data.

Understanding DNS records is where DNS knowledge becomes practical.

Whether you’re launching a website, migrating infrastructure, configuring email, deploying applications, implementing custom domains, or troubleshooting production systems, DNS records sit at the center of the operation.

Why DNS Records Matter More Than Most People Realize

Many internet outages aren’t caused by application bugs.

They aren’t caused by database failures.

They aren’t caused by cloud providers.

They’re caused by configuration mistakes.

A misplaced DNS record can:

Take an entire website offline
Stop customer emails from arriving
Break API connectivity
Prevent SSL certificate issuance
Disrupt SaaS onboarding
Cause search engines to lose access to content

The irony is that DNS records are often configured once and forgotten until something breaks.

That’s why understanding them matters.

DNS Records: The Source of Truth Behind Every Domain

Imagine someone enters:

code

example.com

into a browser.

Eventually the request reaches the authoritative nameserver.

The authoritative nameserver responds with records stored inside its DNS zone.

Example:

code

example.com. IN A 203.0.113.10

The response tells the internet:

code

example.com
       ↓
203.0.113.10

That single record determines where traffic goes.

Without DNS records, DNS itself would be useless.

Understanding DNS Record Types

Modern DNS contains dozens of record types.

However, seven records power the overwhelming majority of websites, applications, email systems, and cloud services.

Record TypePrimary PurposeAMaps hostname to IPv4AAAAMaps hostname to IPv6CNAMECreates aliasesMXRoutes emailTXTVerification and securityNSDefines authoritative nameserversSRVService discovery

These records form the foundation of modern internet infrastructure.

A Record Explained

The A Record is the most fundamental DNS record.

The “A” stands for:

Address

It maps a hostname directly to an IPv4 address.

Example:

code

example.com. IN A 203.0.113.10

This creates a direct relationship:

code

example.com
       ↓
203.0.113.10

When someone visits the domain, traffic is sent to that server.

Why A Records Are So Important

Every website needs a destination.

The A Record provides that destination.

Without it:

Browsers cannot locate servers
Applications cannot connect
APIs become unreachable

Even the most advanced infrastructure eventually depends on records that resolve to an IP address.

Where A Records Are Commonly Used

Typical examples include:

code

company.com
portfolio.com
store.com
api.company.com
app.company.com

Almost every publicly accessible website uses A records somewhere in its architecture.

Production Reality: A Record Migrations

One of the most common infrastructure projects involves moving applications between servers.

For example:

code

Old Server
203.0.113.10

becomes:

code

New Server
203.0.113.50

Updating the A Record redirects traffic globally without requiring users to change anything.

This simple capability is one reason DNS remains such a powerful abstraction layer.

AAAA Record Explained

The AAAA Record performs the same role as an A Record.

The difference is the addressing standard.

RecordProtocolAIPv4AAAAIPv6

Example:

code

example.com. IN AAAA 2001:db8::1

Why IPv6 Exists

IPv4 provides approximately:

code

4.3 Billion Addresses

That seemed enormous in the early days of the internet.

Today, it isn’t.

Cloud computing, smartphones, IoT devices, smart vehicles, and connected infrastructure accelerated address consumption dramatically.

IPv6 was created to solve that limitation.

Should Every Website Use AAAA Records?

Not necessarily.

A common mistake is enabling IPv6 before infrastructure is ready.

If an application doesn’t properly support IPv6, users may experience connectivity problems despite having perfectly functioning IPv4 infrastructure.

IPv6 should be enabled deliberately rather than automatically.

CNAME Record Explained

CNAME stands for:

Canonical Name

Unlike an A Record, a CNAME does not point to an IP address.

Instead, it points to another hostname.

Example:

code

www.example.com IN CNAME example.com

Which effectively means:

code

www.example.com
         ↓
example.com
         ↓
203.0.113.10

Why CNAME Records Exist

Imagine managing:

code

www.example.com
blog.example.com
docs.example.com
shop.example.com

If each hostname pointed directly to an IP address, every infrastructure change would require updating multiple records.

CNAME records eliminate that complexity.

One change updates every dependent hostname.

Why Modern SaaS Platforms Love CNAME Records

Custom domains have become a standard expectation.

Instead of:

code

customer.platform.com

many organizations prefer:

code

app.customer-domain.com

The most common implementation relies on CNAME records.

This approach allows millions of customer domains to connect to shared infrastructure while maintaining branding and flexibility.

The Hidden Complexity of Custom Domains

What appears simple on the surface often requires:

Domain ownership verification
DNS validation
SSL certificate provisioning
Traffic routing
Edge network configuration

Behind a single CNAME record is often a surprisingly sophisticated platform architecture.

CNAME vs A Record

One of the most common questions is:

When should an A Record be used?

When pointing directly to an IP address.

Example:

code

example.com IN A 203.0.113.10

When should a CNAME be used?

When pointing to another hostname.

Example:

code

www.example.com IN CNAME example.com

Simple Rule

Use:

code

A Record

for servers.

Use:

code

CNAME

for aliases.

MX Record Explained

MX stands for:

Mail Exchange

MX records tell the internet where incoming email should be delivered.

Example:

code

example.com IN MX 10 mail.example.com

Without MX records:

Email cannot function.

Why MX Records Matter More Than Most Websites

A website outage is visible.

An email outage often isn’t.

Messages simply disappear.

Leads go unanswered.

Support requests never arrive.

Invoices are missed.

Customers assume silence means neglect.

The business impact can be substantial.

Understanding MX Priority

Example:

code

MX 10 mail-primary.example.com
MX 20 mail-backup.example.com

Lower values receive priority.

If the primary server becomes unavailable, mail automatically flows to the backup system.

This redundancy improves reliability.

TXT Record Explained

TXT records are among the most flexible records in DNS.

Historically they stored simple text.

Today they support critical infrastructure functions.

TXT Records Power Modern Trust Systems

Many internet services rely on TXT records to verify ownership.

Examples include:

Google Search Console
Microsoft 365
Cloud platforms
Email providers
SSL certificate services

Example:

code

google-site-verification=abc123

This proves domain ownership without requiring direct server access.

TXT Records and Email Security

TXT records are heavily used by:

SPF

Defines authorized email senders.

code

v=spf1 include:_spf.google.com ~all

DKIM

Provides cryptographic email signatures.

DMARC

Defines authentication policies.

Together these technologies help reduce:

Email spoofing
Phishing
Domain impersonation

In modern environments, email security is largely a DNS problem before it becomes an email problem.

NS Record Explained

NS stands for:

Name Server

NS records define which nameservers hold authority over a domain.

Example:

code

example.com IN NS ns1.cloudflare.com
example.com IN NS ns2.cloudflare.com

These records tell the internet:

These servers contain the source of truth.

Why NS Records Matter

Without NS records, the DNS hierarchy breaks.

Resolvers would have no way of discovering where authoritative information lives.

Every lookup ultimately depends on NS records.

They form the bridge between domain ownership and DNS management.

A Real Infrastructure Example

A domain may be registered through one provider.

DNS may be hosted elsewhere.

For example:

code

Registrar:
Namecheap

DNS Provider:
Cloudflare

NS records connect those two systems.

SRV Record Explained

SRV stands for:

Service Record

SRV records provide more information than a simple address.

They specify:

Service
Protocol
Port
Priority
Weight

Example:

code

_sip._tcp.example.com

Why SRV Records Exist

Many applications need more than an IP address.

Examples include:

SIP systems
VoIP platforms
Active Directory
Enterprise applications
Gaming infrastructure

SRV records allow applications to discover services automatically.

This reduces manual configuration and improves scalability.

DNS Records Every Modern Website Typically Uses

A standard production setup often includes:

Website Access

code

A Record
CNAME Record

Email Infrastructure

code

MX Record
SPF
DKIM
DMARC

Security and Verification

code

TXT Record

DNS Authority

code

NS Record

DNS Records During Website Migrations

Website migrations often fail because DNS planning is treated as an afterthought.

Common mistakes include:

Forgetting MX records
Removing TXT records
Incorrect TTL settings
Deleting verification records
Breaking email authentication

Successful migrations involve auditing DNS before moving infrastructure.

DNS Records and Search Visibility

DNS records do not directly improve rankings.

However, they influence systems that do.

Reliable DNS supports:

Website availability
Search engine accessibility
Email trust
User experience
Infrastructure reliability

Poor DNS management can undermine otherwise excellent websites.

Quick Reference Table

GoalRecord TypeHost a WebsiteAEnable IPv6AAAACreate an AliasCNAMEReceive EmailMXVerify Domain OwnershipTXTConfigure SPFTXTConfigure DKIMTXTConfigure DMARCTXTDelegate DNS AuthorityNSDiscover ServicesSRV

Key Takeaways

DNS records are the data layer of DNS.
A Records connect hostnames to IPv4 addresses.
AAAA Records connect hostnames to IPv6 addresses.
CNAME Records create aliases.
MX Records control email routing.
TXT Records power verification and security.
NS Records define authoritative nameservers.
SRV Records support service discovery.
Modern websites, cloud platforms, SaaS applications, and email systems depend on DNS records.
Understanding DNS records helps prevent outages, improve reliability, and simplify infrastructure management.

What’s Next?

At this point, we’ve covered:

✓ How DNS works

✓ How DNS records work

✓ The role of A, AAAA, CNAME, MX, TXT, NS, and SRV records

The next logical question is:

Does DNS infrastructure affect search visibility?

DNS Explained: The Complete Guide for Founders, Developers, and Modern Businesses

Anik Sikder — Sat, 08 Aug 2026 17:02:17 +0000

Most people don’t think about DNS until something breaks.

A founder launches a new website and suddenly email stops working.

A developer migrates infrastructure and traffic starts disappearing.

A marketing team changes a domain setting and the website becomes unreachable.

A SaaS company adds custom domains and discovers that domain management is far more complicated than expected.

The reality is simple:

DNS is one of the most critical systems on the internet, yet it’s one of the least understood.

Every website, API, SaaS platform, email service, mobile application, cloud platform, and online business depends on DNS.

Google depends on DNS.

Cloudflare depends on DNS.

AWS depends on DNS.

Your startup depends on DNS.

And while DNS often appears simple from the outside, there is an incredible amount of engineering hidden beneath a single domain lookup.

This article is designed for both founders and developers.

If you’re a founder, you’ll understand how DNS impacts business continuity, SEO, security, email delivery, and customer experience.

If you’re a developer, you’ll understand how DNS resolution actually works, why DNS records matter, how cloud platforms use DNS internally, and how production-grade systems are built around it.

Let’s start at the beginning.

What Is DNS?

DNS stands for:

Domain Name System

The easiest explanation is:

DNS translates human-friendly names into machine-friendly addresses.

Humans prefer:

code

openai.com

Computers prefer:

code

104.18.33.45

DNS acts as the translation layer between those two worlds.

Without DNS, every website visit would require memorizing numerical IP addresses.

Instead of typing:

code

google.com

you would need to type something similar to:

code

142.250.190.78

for every website you wanted to visit.

Clearly, that wouldn’t scale.

DNS solves this problem by creating a globally distributed naming system.

DNS Is the Internet’s Directory Service

Imagine the internet as a massive city.

Every building has a street address.

Computers only understand addresses.

Humans prefer names.

DNS functions like a directory service that translates:

code

Company Name
        ↓
Street Address

code

Domain Name
        ↓
IP Address

The idea sounds simple.

The engineering required to make this work globally, reliably, and within milliseconds is not.

Why Founders Should Care About DNS

Many founders think DNS is purely a technical concern.

That’s a mistake.

DNS directly affects:

Website Availability

If DNS fails:

Your website disappears.

Not slow.

Not degraded.

Gone.

Users can’t reach it.

Search engines can’t crawl it.

Customers can’t buy from it.

Email Delivery

Many businesses discover DNS only after email breaks.

DNS controls:

Google Workspace
Microsoft 365
Zoho Mail
Custom email servers

A single DNS mistake can prevent:

Sales emails
Customer support
Password resets
Transactional notifications

from reaching users.

SEO Performance

DNS impacts:

Availability
Website speed
Crawlability
User experience

Search engines cannot rank websites they cannot consistently access.

Brand Trust

Imagine a customer visiting:

code

yourbusiness.com

and seeing:

code

This site can't be reached

Trust disappears instantly.

DNS is part of your brand infrastructure.

Why Developers Must Understand DNS

Modern development isn’t just writing code.

Today developers manage:

APIs
Cloud infrastructure
Containers
Load balancers
SSL certificates
SaaS platforms
Multi-region deployments

DNS sits in the middle of all of them.

A surprising number of production incidents ultimately trace back to DNS.

Understanding DNS turns infrastructure troubleshooting from guesswork into engineering.

The DNS Resolution Process

When a user enters:

code

www.example.com

inside a browser, what actually happens?

Most people imagine:

code

Browser
    ↓
Website

Reality is significantly more complex.

Step 1: Browser Cache

The browser first asks:

Have I looked up this domain recently?

If yes:

The browser already knows the answer.

No external DNS request is needed.

The website loads immediately.

This is called DNS caching.

Step 2: Operating System Cache

If the browser doesn’t know the answer, it asks the operating system.

Windows, Linux, macOS, Android, and iOS maintain DNS caches.

Again:

If the answer exists locally, the process ends here.

Step 3: Recursive Resolver

If no cached answer exists, the request reaches a recursive DNS resolver.

Examples include:

Cloudflare DNS:

code

1.1.1.1

Google DNS:

code

8.8.8.8

Your ISP’s DNS servers.

The resolver’s job is:

Find the answer on behalf of the user.

Step 4: Root Nameservers

The resolver begins at the top of the DNS hierarchy.

The internet contains root DNS servers.

These servers don’t know the IP address of every website.

Instead they know:

Which servers are responsible for top-level domains.

For example:

code

.com
.org
.net
.io
.dev

Step 5: Top-Level Domain Servers

Suppose you’re looking for:

code

example.com

The root server responds:

Ask the .com nameservers.

The resolver now contacts the .com infrastructure.

Step 6: Authoritative Nameservers

The .com servers respond:

The authoritative DNS servers for example.com are located here.

Now the resolver knows exactly where to find the truth.

Step 7: Final Answer

The authoritative DNS server returns:

code

203.0.113.10

The resolver caches the answer.

The browser receives the answer.

The website loads.

All of this often happens in less than 100 milliseconds.

The DNS Hierarchy

DNS is not a giant database.

It’s a distributed hierarchy.

Think of it as:

code

Root
 ├── .com
 ├── .org
 ├── .net
 ├── .io
 └── .dev

Under each TLD:

code

example.com
openai.com
github.com

Under each domain:

code

www.example.com
api.example.com
mail.example.com

This hierarchical design is one reason DNS scales globally.

Understanding DNS Records

DNS records are instructions.

Different record types solve different problems.

Understanding them is essential for production systems.

A Record

Maps a hostname to an IPv4 address.

Example:

code

example.com. IN A 203.0.113.10

This is the most common DNS record.

AAAA Record

Maps a hostname to an IPv6 address.

Example:

code

example.com. IN AAAA 2001:db8::1

IPv6 adoption continues growing across cloud providers and ISPs.

CNAME Record

Creates an alias.

Example:

code

www.example.com IN CNAME example.com

Useful when multiple hostnames point to the same service.

MX Record

Controls email routing.

Example:

code

example.com IN MX 10 mail.example.com

Without MX records:

Email fails.

TXT Records

One of the most versatile DNS record types.

Used for:

Domain verification
SPF
DKIM
DMARC
Third-party integrations

Founders often encounter TXT records when connecting:

Google Workspace
Microsoft 365
Search Console
Cloud providers

NS Records

NS records define authoritative nameservers.

Example:

code

example.com IN NS ns1.provider.com
example.com IN NS ns2.provider.com

These servers become responsible for your DNS zone.

Why DNS Propagation Takes Time

One of the most common questions:

Why isn’t my DNS change working?

Usually because of caching.

Understanding TTL

TTL means:

Time To Live

Example:

code

TTL = 3600

This means:

code

Cache for 1 hour

Resolvers keep answers cached until TTL expires.

The Truth About DNS Propagation

DNS doesn’t actually “spread” changes.

Resolvers simply stop trusting cached data and ask again.

This process creates the appearance of propagation.

Understanding this distinction helps developers troubleshoot DNS issues more effectively.

DNS and Website Performance

DNS is the first network request most users make.

Before:

HTML
CSS
JavaScript
APIs

DNS must succeed.

Slow DNS creates slower websites.

Measuring DNS Performance

Common metrics include:

DNS lookup time
TTFB
Latency
Availability

A slow DNS provider adds measurable delays before page rendering begins.

DNS and SEO

Many SEO guides barely discuss DNS.

That’s unfortunate because DNS indirectly impacts search performance.

Availability Matters

Search engines need consistent access.

If DNS failures occur:

Crawling suffers
Indexing suffers
Rankings may suffer

Performance Matters

Google increasingly rewards user experience.

Fast DNS contributes to:

Faster page loads
Better engagement
Improved performance metrics

Reliability Matters

Enterprise-grade DNS infrastructure improves uptime.

Uptime improves trust.

Trust improves long-term search visibility.

DNS and GEO (Generative Engine Optimization)

A new challenge is emerging.

Users increasingly discover businesses through AI systems.

Large language models, AI search engines, and answer engines rely heavily on accessible infrastructure.

Reliable DNS contributes to:

Consistent crawling
Better accessibility
Reliable content retrieval

As GEO evolves, infrastructure quality becomes increasingly important.

DNS Security Explained

DNS is also a major attack surface.

DNS Spoofing

Attackers attempt to redirect users toward malicious destinations.

The victim enters:

code

bank.com

but reaches:

code

attacker-site.com

without realizing it.

DNS Cache Poisoning

Attackers inject false DNS responses into caches.

Users receive incorrect answers.

This can lead to phishing and credential theft.

DNSSEC

DNSSEC adds cryptographic signatures.

Benefits include:

Authenticity
Integrity
Protection against spoofing

DNSSEC doesn’t encrypt DNS.

It verifies DNS.

That’s an important distinction.

Email Authentication and DNS

Email security relies heavily on DNS.

Three records are especially important.

SPF

Defines which servers can send email.

DKIM

Provides cryptographic email signatures.

DMARC

Defines enforcement policies.

Together they reduce:

Spoofing
Phishing
Email fraud

How Cloud Providers Use DNS

Cloud infrastructure relies heavily on DNS.

AWS.

Azure.

Google Cloud.

Cloudflare.

DigitalOcean.

All use DNS extensively.

Load Balancing

DNS can distribute traffic.

Example:

code

app.example.com

might resolve to multiple servers.

Benefits:

Scalability
Redundancy
Reliability

Geographic Routing

Users in Singapore may reach Asian infrastructure.

Users in Germany may reach European infrastructure.

Users in New York may reach US infrastructure.

DNS can make these routing decisions automatically.

DNS for SaaS Applications

This is where things become particularly interesting.

Suppose you’re building a SaaS platform.

Your customers want:

code

client-company.com

instead of:

code

client.yourapp.com

This requires custom domain support.

Custom domain support requires DNS verification.

DNS verification requires ownership validation.

DNS becomes part of your product architecture.

Many SaaS founders underestimate this complexity.

Common DNS Mistakes in Production

Over the years, the same mistakes appear repeatedly.

Deleting Records Accidentally

Migration projects frequently break email because MX records were forgotten.

Ignoring TTL

Developers make changes expecting instant results.

DNS doesn’t work that way.

No DNS Monitoring

Businesses discover outages from customers instead of monitoring systems.

No Redundancy

Single-provider DNS creates unnecessary risk.

Missing Email Security Records

SPF, DKIM, and DMARC are often ignored until deliverability problems appear.

Practical DNS Tools Every Developer Should Know

dig

code

dig example.com

The gold standard for DNS troubleshooting.

nslookup

code

nslookup example.com

Widely available across operating systems.

host

code

host example.com

Quick and simple DNS lookups.

whois

code

whois example.com

Useful for domain ownership and registration information.

Key Takeaways

DNS is the internet’s naming system.
Every website, API, email service, and cloud platform relies on DNS.
DNS translates domain names into IP addresses.
DNS is hierarchical and globally distributed.
DNS records control websites, email, security, and service routing.
DNS impacts performance, reliability, SEO, and user experience.
DNSSEC improves DNS trust and authenticity.
SaaS applications often depend heavily on DNS architecture.
Understanding DNS is valuable for founders and essential for developers.

Final Thoughts

The best infrastructure is often invisible.

Users never think about DNS when everything works.

Yet every successful online business depends on it.

Founders view DNS as a domain setting.

Developers eventually realize it’s a foundational internet protocol.

The deeper you go into cloud architecture, distributed systems, SaaS platforms, cybersecurity, and modern software engineering, the more often you’ll encounter DNS.

Understanding DNS isn’t just about configuring records.

It’s about understanding how the internet itself finds, trusts, and connects systems together.

And once you understand that, you’ll start seeing DNS everywhere.

Multiplexing vs Connection Pooling: Why HTTP/2 Changed Everything

Anik Sikder — Sat, 01 Aug 2026 14:47:07 +0000

In the previous articles of this series, we explored a recurring theme:

Every generation of web infrastructure solved one bottleneck only to expose another.

HTTP/1.0 suffered from connection setup overhead.
HTTP/1.1 introduced persistent connections.
Then browsers started requesting hundreds of assets.
Persistent connections helped, but a new problem emerged: Head-of-Line Blocking.
To work around it, browsers began opening multiple TCP connections.

That workaround became known as Connection Pooling.

For years, Connection Pooling was the hidden engine powering the modern web.

Then HTTP/2 arrived and asked a dangerous question:

What if we stopped opening more connections and instead made a single connection smarter?

That idea became Multiplexing.

This article explores why that shift fundamentally changed web architecture.

The Problem Nobody Intended to Create

Imagine it's 2012.

A user opens your e-commerce homepage.

The browser needs:

HTML
CSS files
JavaScript bundles
Product images
Recommendation widgets
Analytics scripts
Tracking pixels
Fonts

A single page can easily require:

100+ requests

Yet HTTP/1.1 processes requests sequentially on a connection.

Connection 1

Request A
Response A

Request B
Response B

Request C
Response C

The browser quickly discovers something painful:

If Request A is slow,

everything behind it waits.

This becomes Head-of-Line Blocking.

The First Large-Scale Workaround

Browser vendors couldn't change HTTP overnight.

So they found another solution.

Open more TCP connections.

Instead of:

1 Connection
100 Requests

Browsers evolved toward:

Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
Connection 6

Each connection handles separate requests.

Example:

Connection 1 -> CSS
Connection 2 -> JS
Connection 3 -> Image
Connection 4 -> Image
Connection 5 -> Font
Connection 6 -> API

Now multiple requests can progress simultaneously.

This dramatically improved page load performance.

The strategy became known as:

Connection Pooling

What Exactly Is Connection Pooling?

Connection Pooling means maintaining a collection of reusable connections instead of creating a new connection for every request.

Instead of:

Request
Create TCP
TLS
Send
Close

for every operation,

the browser maintains a pool:

Pool

Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
Connection 6

Incoming requests are assigned to available connections.

Request A -> Connection 1
Request B -> Connection 2
Request C -> Connection 3

This reduces:

TCP handshake cost
TLS handshake cost
Connection setup latency

For years, this approach worked surprisingly well.

But it introduced new operational problems.

Postmortem: The Scaling Problem Nobody Talks About

Imagine a popular online marketplace.

Traffic:

500,000 active users

Browser behavior:

6 connections per origin

Potential active connections:

3,000,000 TCP connections

Now consider the infrastructure.

Every connection consumes:

Memory
Kernel resources
TCP buffers
TLS state

Suddenly the architecture team realizes:

We are spending more resources managing connections than delivering content.

The system is technically healthy.

Yet servers remain under pressure.

Not because requests are expensive.

Because connections are expensive.

The Hidden Cost of Connection Pooling

Most performance discussions focus on requests.

Infrastructure teams focus on connections.

Each TCP connection carries overhead.

Example:

Client
   │
TCP State
TLS State
Receive Buffer
Send Buffer
Kernel Metadata
   │
Server

Multiply this by millions of active connections.

The resource footprint becomes enormous.

This is why large-scale systems obsess over connection efficiency.

Another Problem: Congestion Control

Each TCP connection behaves independently.

Imagine six connections:

Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
Connection 6

Each has:

Its own congestion window
Its own retransmissions
Its own packet loss handling

The network now sees six competing traffic flows from the same browser.

This is inefficient.

The browser is essentially pretending to be six different clients.

The protocol wasn't designed for this.

It was a workaround.

The HTTP/2 Idea

Engineers looked at the situation and asked:

Why are we creating six connections just to achieve parallelism?

What if one connection could handle many requests simultaneously?

Instead of:

Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
Connection 6

Use:

Connection 1
 ├─ Request A
 ├─ Request B
 ├─ Request C
 ├─ Request D
 ├─ Request E

One connection.

Many independent conversations.

That idea became:

Multiplexing

Understanding Multiplexing

In HTTP/2, requests no longer own connections.

They own streams.

TCP Connection
     │
 ┌───┼───────────┐
 │   │           │
Stream 1
Stream 2
Stream 3
Stream 4
Stream 5

Each request receives its own stream.

Example:

Stream 1 -> CSS
Stream 2 -> JS
Stream 3 -> Image
Stream 4 -> API
Stream 5 -> Font

All streams share the same TCP connection.

The Magic: Interleaving

HTTP/1.1:

Request A
Response A
Request B
Response B

HTTP/2:

A1
B1
C1
A2
B2
C2
A3
B3
C3

Data from different streams becomes interleaved.

The connection continuously carries frames from multiple requests.

No request owns the connection.

The connection belongs to everyone.

This is true multiplexing.

Real Example: Product Page Load

Suppose a product page requires:

HTML
5 CSS files
10 JS files
20 images
2 APIs

HTTP/1.1:

Browser

Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
Connection 6

Requests are distributed across the pool.

Some connections become idle.

Others become overloaded.

Load balancing is imperfect.

HTTP/2:

Single Connection

Stream 1
Stream 2
Stream 3
...
Stream 38

All resources travel simultaneously through the same connection.

The browser no longer plays connection management games.

The protocol handles concurrency natively.

The Business Impact

Most executives never hear the term Multiplexing.

They only see metrics.

Before:

Page Load Time: 4.2s
Bounce Rate: Higher
Conversion Rate: Lower

After optimization:

Page Load Time: 2.8s
Bounce Rate: Lower
Conversion Rate: Higher

Users do not care whether the improvement came from:

TCP tuning
Multiplexing
Compression
Prioritization

They only experience speed.

For many businesses:

Faster Pages
=
More Revenue

The Developer Impact

Before HTTP/2, frontend engineers developed strange habits.

Examples:

CSS Sprites

Combining many images into one file.

icon1.png
icon2.png
icon3.png

became

sprites.png

JavaScript Bundling

20 JS Files

became

app.bundle.js

Domain Sharding

img1.example.com
img2.example.com
img3.example.com

This trick forced browsers to create more connection pools.

These techniques existed largely because HTTP/1.1 had connection limitations.

Multiplexing removed many of those constraints.

The Postmortem Nobody Expected

Many teams upgraded to HTTP/2 expecting:

6 Connections
↓
1 Connection
↓
6x Faster

Reality was more complicated.

A surprising issue emerged.

HTTP/2 still runs on:

TCP

And TCP still suffers from packet loss.

If a packet is lost:

TCP waits
TCP retransmits
TCP recovers

All streams share that same connection.

Meaning:

Stream 1 waits
Stream 2 waits
Stream 3 waits
Stream 4 waits

This became a new form of Head-of-Line Blocking.

Not at the HTTP layer.

At the TCP layer.

HTTP/2 solved one bottleneck while exposing another.

Exactly the same pattern we've seen throughout internet history.

Connection Pooling vs Multiplexing

Connection Pooling:

Many Connections
One Request Flow Per Connection
Parallelism Through More Connections

Connection 1 -> Request A
Connection 2 -> Request B
Connection 3 -> Request C

Multiplexing:

One Connection
Many Streams
Parallelism Inside Connection

Connection 1
 ├─ Stream A
 ├─ Stream B
 ├─ Stream C

Connection Pooling optimizes:

Connection Reuse

Multiplexing optimizes:

Connection Utilization

Connection Pooling says:

Let's create several reusable highways.

Multiplexing says:

Let's build one intelligent highway with many lanes.

The Bigger Lesson

Connection Pooling was never the final destination.

It was an engineering workaround.

Multiplexing was the architectural correction.

The web spent years fighting the limitations of HTTP/1.1 by opening more and more connections.

HTTP/2 changed the question entirely.

Instead of asking:

"How many connections do we need?"

Engineers began asking:

"How much work can one connection perform?"

That shift seems small.

But it fundamentally changed how browsers, servers, load balancers, CDNs, and modern applications communicate.

And it paved the road for the next evolution of the web:

HTTP/3 and QUIC, where engineers finally attempted to eliminate TCP-level Head-of-Line Blocking itself.

Publish-Subscribe: How Modern Systems Scale Without Becoming a Monolith

Anik Sikder — Thu, 30 Jul 2026 17:53:36 +0000

When an online order is placed, the customer sees a simple message:

"Your order has been confirmed."

Behind that message, however, an entire chain of events begins.

The inventory must be updated.

The payment must be recorded.

The customer should receive an email.

Analytics dashboards need updating.

Fraud detection systems may need to run.

Loyalty points might need to be awarded.

Shipping labels may need to be generated.

In small systems, developers often connect these actions directly.

Order Service
 ├── Update Inventory
 ├── Send Email
 ├── Update Analytics
 ├── Create Invoice
 └── Start Shipping

At first, this seems perfectly reasonable.

Then the business grows.

And everything starts breaking.

The Architecture That Works Until It Doesn't

Imagine an e-commerce platform processing 50 orders per day.

A customer places an order.

The Order Service directly calls:

Inventory Service
Email Service
Analytics Service
Billing Service
Shipping Service

Everything succeeds.

Everyone is happy.

The architecture appears simple.

The problem is that simplicity is deceptive.

The Order Service now depends on every downstream service.

If any one of them is slow, the entire workflow becomes slow.

If any one of them fails, the customer experience can fail.

The more business capabilities added, the larger this dependency chain becomes.

Over time the Order Service quietly transforms into the center of the entire company.

Every new feature adds another dependency.

Every new dependency increases risk.

A Real Failure Scenario

Consider this order workflow:

Customer
    ↓
Order Service
    ↓
Inventory Service
    ↓
Email Service
    ↓
Analytics Service

One day the Email Service experiences an outage.

Now what happens?

Many systems accidentally end up with behavior like this:

create_order()

reserve_inventory()

send_confirmation_email()

update_analytics()

Email fails.

The transaction stops.

Analytics never updates.

The customer may not even receive order confirmation.

A problem in one subsystem cascades across the platform.

This is known as tight coupling.

The services are technically separate.

Operationally, they are not.

The Postmortem Nobody Wants to Write

A common production incident looks something like this:

What happened?

A third-party email provider experienced elevated latency.

Impact

Order creation response times increased from:

200ms

8-15 seconds

Business Impact

Customers abandoned checkout.

Conversion rates dropped.

Support tickets increased.

Revenue was affected.

Root Cause

The Order Service was waiting for Email Service completion before responding.

Architectural Problem

The platform treated a non-critical operation as a critical dependency.

Notice something important.

The email system wasn't actually required to create the order.

The order should have succeeded regardless.

The architecture created the outage.

Not the email provider.

Enter Publish-Subscribe

Instead of directly calling every service, the Order Service publishes an event.

Order Service
      ↓
Order Created Event
      ↓
Message Broker
      ↓
Inventory
Email
Analytics
Billing
Shipping

Now the Order Service only has one responsibility:

Create Order
Publish Event
Done

It no longer cares who needs the information.

It simply announces:

Order Created

Anyone interested can react.

This changes everything.

Thinking in Events Instead of Calls

Traditional systems think:

Do this.
Then do that.
Then do another thing.

Event-driven systems think:

Something happened.
Whoever cares can respond.

That shift sounds small.

Architecturally, it is enormous.

The producer no longer knows:

Who consumes the event
How many consumers exist
When consumers process it
What consumers do with it

The producer simply publishes facts.

The Message Broker Becomes the Traffic Controller

A message broker sits between producers and consumers.

Examples include:

Apache Kafka
RabbitMQ
Amazon SNS
Amazon SQS

The broker receives events and distributes them to interested systems.

Publisher
    ↓
Broker
 ├── Inventory
 ├── Email
 ├── Billing
 ├── Analytics
 └── Fraud Detection

Services no longer communicate directly.

The broker acts as the central nervous system.

Why Business Leaders Should Care

Most architectural decisions eventually become business decisions.

Publish-Subscribe creates advantages that executives feel directly.

Faster Feature Delivery

Imagine marketing wants a loyalty points system.

In a tightly coupled architecture:

Modify Order Service
Retest Order Service
Redeploy Order Service
Risk Order Service

In Pub/Sub:

Create Loyalty Consumer
Subscribe to Order Created
Deploy Independently

The order system remains untouched.

New business capabilities can be added safely.

Reduced Revenue Risk

If Analytics fails:

Orders continue.
Payments continue.
Customers continue.

Only analytics is affected.

The failure is isolated.

This dramatically reduces blast radius.

Better Organizational Scaling

As companies grow:

Payments Team
Inventory Team
Data Team
Growth Team
Customer Team

Each team can consume events independently.

Teams become less dependent on one another.

This increases development velocity.

Why Developers Love Event-Driven Systems

Developers eventually discover a painful truth:

The hardest part of scaling is not traffic.

It's dependencies.

Pub/Sub removes many of them.

Loose Coupling

Without Pub/Sub:

Order Service
    ↓
Inventory
    ↓
Email
    ↓
Analytics

With Pub/Sub:

Order Service
      ↓
Broker
      ↓
Consumers

The producer has one dependency.

Instead of ten.

Independent Deployments

A team can deploy:

Recommendation Engine
Fraud Detection
Customer Segmentation

without touching the ordering system.

This dramatically reduces deployment risk.

Better Resilience

Suppose Billing Service crashes.

The broker stores events.

When Billing returns:

Order Created Event #1001
Order Created Event #1002
Order Created Event #1003

can still be processed.

The platform recovers automatically.

But Publish-Subscribe Creates New Problems

Many architecture articles stop at benefits.

Production systems do not.

Every architectural gain introduces tradeoffs.

Problem #1: Eventual Consistency

In synchronous systems:

Order Created
Inventory Updated
Response Returned

Everything happens immediately.

In Pub/Sub:

Order Created
Response Returned

Inventory Updated Later

There is now a time gap.

Systems may temporarily disagree.

This is called:

Eventual Consistency

One of the most misunderstood realities of distributed systems.

Problem #2: Duplicate Events

Networks fail.

Retries happen.

Consumers crash.

The same event may arrive twice.

Order Created #123
Order Created #123

Consumers must be idempotent.

Otherwise:

Inventory reduced twice
Customer charged twice

Production incidents happen.

Problem #3: Observability Becomes Hard

In monolithic workflows:

Request → Response

Easy to trace.

In event-driven systems:

Order Created
    ↓
Inventory Updated
    ↓
Billing Created
    ↓
Email Sent
    ↓
Analytics Updated

A single customer action can generate dozens of events.

Tracking failures becomes significantly harder.

This is why mature organizations invest heavily in:

Distributed tracing
Correlation IDs
Event monitoring
Audit logs

How Large Platforms Actually Think

The most successful architectures do not ask:

"Which service should call which?"

Instead they ask:

"What business events exist?"

Examples:

Order Created
Payment Authorized
Shipment Created
Invoice Generated
User Registered
Subscription Renewed

These events become the language of the business.

Systems are then built around reacting to those events.

The result is an architecture that grows with the company instead of fighting it.

The Real Lesson

Publish-Subscribe is not primarily about messaging.

It is about organizational scalability.

It allows systems to evolve without every team depending on every other team.

It reduces blast radius.

It improves resilience.

It accelerates feature delivery.

But it also introduces complexity, eventual consistency, and operational challenges that teams must be prepared to handle.

The companies that scale successfully are rarely the ones with the most services.

They are the ones with the clearest events.

Because once systems start speaking in events instead of direct dependencies, growth becomes far easier to sustain.

Key Takeaway

A mature architecture doesn't ask:

"Who should I call next?"

It asks:

"What happened?"

That single shift from commands to events is one of the biggest architectural transitions in modern software systems.

Server-Sent Events (SSE): When the Web Learned to Listen

Anik Sikder — Mon, 27 Jul 2026 16:58:10 +0000

For years, the web operated on a simple principle:

Browser asks.
Server answers.
Connection closes.

This model worked perfectly when websites were mostly documents.

A user opened a page.

The browser requested data.

The server responded.

Everyone moved on.

But then the internet changed.

Businesses wanted live stock prices.

Operations teams wanted real-time monitoring dashboards.

Support agents wanted instant notifications.

Users expected applications to update the moment something happened.

The old request-response model suddenly felt too slow.

The challenge wasn't that servers couldn't produce updates quickly.

The challenge was getting those updates to users immediately.

And that led engineers down a fascinating path:

Request-Response
        ↓
Polling
        ↓
Long Polling
        ↓
Server-Sent Events (SSE)

SSE wasn't just another protocol.

It was the web's attempt to become truly real-time while still staying within the familiar world of HTTP.

The Business Problem Nobody Could Ignore

Imagine you're running a stock trading platform.

At market open, prices can change thousands of times every second.

Your users expect something like this:

AAPL  $202.15
MSFT  $541.22
NVDA  $193.47

And when prices change:

AAPL  $202.31
MSFT  $541.40
NVDA  $193.61

The update should appear instantly.

Not five seconds later.

Not after a page refresh.

Not after clicking a button.

Immediately.

From a business perspective, this sounds simple:

"Show customers the latest information as soon as it changes."

From a system design perspective, it's much harder.

How does the browser know when something changes?

The First Attempt: Polling

The most obvious solution was polling.

The browser repeatedly asked:

Any updates?

Every few seconds.

Browser
    │
    ├── Request
    ├── Request
    ├── Request
    ├── Request
    └── Request

Most of the time the server replied:

Nothing changed.

Imagine 100,000 users checking every second.

Even when no new information existed:

100,000 Requests
          ↓
100,000 Responses
          ↓
No Useful Data

The system was working hard to accomplish almost nothing.

The architecture scaled poorly.

Infrastructure costs increased.

Servers processed millions of unnecessary requests.

Engineers needed something better.

The Second Attempt: Long Polling

Long Polling improved efficiency.

Instead of responding immediately, the server waited.

Browser Request
       ↓
Server Waits
       ↓
Event Happens
       ↓
Server Responds

If a stock price changed, the server responded instantly.

If nothing happened, the connection stayed open.

This dramatically reduced useless requests.

But Long Polling still had a problem.

After every response:

Response Received
        ↓
Create New Request
        ↓
Wait Again

The cycle never truly disappeared.

The browser was still repeatedly initiating communication.

Just less frequently.

The Simple Question That Changed Everything

Eventually engineers asked:

Why is the browser constantly asking for updates?

If the server already knows when something changes, why not let the server send the update directly?

That question led to Server-Sent Events.

What Is Server-Sent Events (SSE)?

Server-Sent Events allow a browser to open a single HTTP connection and keep it alive.

Instead of repeatedly asking for information, the browser simply listens.

Browser
     │
     │ Open Connection
     ▼
Server
     │
     ├── Event
     ├── Event
     ├── Event
     └── Event

The server pushes updates whenever something happens.

No polling loop.

No repeated requests.

No constant reconnecting.

The browser becomes a subscriber.

The server becomes a publisher.

A Different Way of Thinking

Polling asks:

Did anything happen?
Did anything happen?
Did anything happen?
Did anything happen?

SSE says:

Tell me when something happens.

That sounds like a small difference.

Architecturally, it's huge.

Inside a Real SSE Connection

From the browser's perspective, creating an SSE connection is surprisingly simple.

const events = new EventSource("/events");

The browser sends a normal HTTP request.

The server responds with a special content type:

text/event-stream

But unlike a normal HTTP response, the server doesn't close the connection.

Instead, it keeps streaming data.

data: New Order Created

data: Payment Received

data: Shipment Dispatched

The browser receives each event immediately.

The connection remains open.

The stream continues.

Real System Example: E-Commerce Operations Dashboard

Consider a large e-commerce company.

The operations team monitors incoming orders in real time.

Without SSE:

Dashboard
    ↓
Poll Every 5 Seconds
    ↓
Check For New Orders

A customer places an order.

The operations team might not see it for several seconds.

With SSE:

Customer Places Order
          ↓
Order Service
          ↓
Event Bus
          ↓
Notification Service
          ↓
SSE Gateway
          ↓
Dashboard

The moment the order is created:

New Order Received

appears on the dashboard.

No refresh required.

No polling required.

To the user, the system feels alive.

Real System Example: Monitoring Platforms

Modern monitoring tools often display:

CPU utilization
Memory usage
Error rates
Request latency
Active users

Imagine a platform monitoring thousands of servers.

Every metric changes continuously.

Polling every few seconds creates unnecessary traffic.

Instead:

Monitoring Agent
  ↓
Metrics Service
  ↓
Event Stream
  ↓
SSE
  ↓
Dashboard

As metrics change, updates appear instantly.

Operations teams gain near real-time visibility into system health.

Real System Example: AI Response Streaming

Today, one of the most recognizable uses of SSE is AI.

When you ask ChatGPT a question, the model doesn't generate an entire response instantly.

It generates tokens one at a time.

Without streaming:

User Question
       ↓
Wait 10 Seconds
       ↓
Entire Answer Appears

From the user's perspective:

System feels slow.

With SSE:

User Question
       ↓
Wait 1 Second
       ↓
Words Begin Appearing
       ↓
Response Continues Streaming

The total generation time may still be ten seconds.

But the experience feels dramatically faster.

This reveals an important system design principle:

Users experience latency differently than systems measure latency.

A ten-second wait feels frustrating.

A ten-second stream feels interactive.

SSE helps bridge that gap.

This is one reason AI products feel conversational rather than delayed.

Why Product Teams Love SSE

From a product perspective, SSE improves perceived responsiveness.

Users don't care how elegant your architecture is.

They care about what they see.

Compare:

Click
     ↓
Wait
     ↓
Wait
     ↓
Wait
     ↓
Response

Versus:

Click
     ↓
Response Starts
     ↓
More Content
     ↓
More Content

The second experience feels dramatically faster even if total processing time is identical.

That translates directly into:

Better engagement
Better user satisfaction
Higher retention
More trust in the product

Why Developers Love SSE

One reason SSE became popular is that it works with existing HTTP infrastructure.

There is no entirely new protocol to learn.

Browser
   ↓
HTTP
   ↓
Load Balancer
   ↓
Reverse Proxy
   ↓
Application Server

Everything already understands HTTP.

This makes adoption much easier.

Developers also benefit from automatic reconnection.

If a connection drops:

Connection Lost
        ↓
Browser Detects Failure
        ↓
Automatic Reconnect

The browser handles much of the recovery logic automatically.

Less code.

Less complexity.

Fewer edge cases.

Why Architects Choose SSE

A common question is:

Why not just use WebSockets?

The answer depends on communication patterns.

Consider stock prices:

Market
   ↓
User

Or monitoring dashboards:

Server
   ↓
Dashboard

Or AI response streaming:

Model
   ↓
Browser

In all of these systems:

Server talks constantly.
Client rarely talks.

SSE fits naturally.

WebSockets support two-way communication:

Client ↔ Server

But many systems don't need that capability.

Using WebSockets in these situations can introduce complexity without delivering meaningful benefits.

One of the most important lessons in architecture is:

The best solution is not the most powerful one. It's the simplest one that satisfies the requirements.

For many one-way streaming workloads, SSE is exactly that solution.

The Hidden Challenge

Every architectural improvement introduces a new bottleneck.

Polling creates too many requests.

SSE solves that problem.

But it introduces another.

Persistent connections.

Imagine:

500,000 Active Users

Polling might create:

Millions of Requests Per Minute

SSE creates:

500,000 Open Connections

The request problem improves.

The connection management problem appears.

Infrastructure teams now worry about:

Memory consumption
File descriptor limits
Load balancer behavior
Proxy timeouts
Reconnection storms
Horizontal scaling

From an operations perspective:

Fewer Requests
≠
Less Work

The workload simply shifts.

Where SSE Starts To Break Down

SSE is excellent for one-way communication.

But some systems require continuous communication in both directions.

Examples include:

Chat applications
Multiplayer games
Collaborative editors
Trading platforms
Video conferencing systems

These applications need:

Client ↔ Server

communication.

SSE only provides:

Server → Client

At that point, WebSockets usually become the better architectural choice.

What SSE Really Changed

Server-Sent Events didn't introduce a revolutionary new protocol.

Its impact came from a much simpler idea:

Stop asking repeatedly.

Start listening continuously.

That shift helped transform the web from a collection of documents into a platform for real-time experiences.

Stock prices could update instantly.

Dashboards could refresh automatically.

Notifications could arrive the moment events occurred.

AI systems could stream responses as they were generated.

The technology itself is relatively simple.

The effect on user experience is enormous.

And that is often the hallmark of great system design:

A small architectural change that fundamentally improves how users experience a system.

The Evolution Continues

The web's journey toward real-time communication didn't stop with SSE.

Request-Response
   ↓
Polling
   ↓
Long Polling
   ↓
Server-Sent Events (SSE)
   ↓
WebSockets

SSE taught the web how to stream information.

WebSockets would teach the web how to have a conversation.

And that's where the next chapter begins.

Long Polling : The First Time the Web Tried to Feel Alive

Anik Sikder — Sat, 25 Jul 2026 17:22:07 +0000

In the previous article, we explored traditional polling.

At first glance, polling seemed like a reasonable solution.

A browser simply asked the server:

"Anything new?"

If nothing changed:

{
  "updates": []
}

The browser waited a few seconds and asked again.

Simple.

Predictable.

Easy to implement.

For small systems, it worked perfectly.

But then users changed.

And suddenly, polling became a business problem.

The Incident Nobody Talks About

Imagine it's 2008.

You're part of an engineering team building a rapidly growing social platform.

Your CEO walks into the room and says:

"Users are complaining that messages feel slow."

The database is healthy.

The servers are healthy.

The network is healthy.

Yet users are unhappy.

Why?

Because technology was measuring milliseconds.

Users were measuring feelings.

To them:

Message Sent
       │
       ▼
Nothing Happens
       │
       ▼
3 Seconds Later...
       │
       ▼
Message Appears

The application felt broken.

Not because it was slow.

Because it wasn't instant.

And expectations were changing.

The Product Team's Suggestion

The product manager proposes a simple solution.

"Let's poll more often."

Instead of every 10 seconds:

Poll Every 1 Second

Everyone nods.

Problem solved.

Or so they think.

Three weeks later, infrastructure costs spike.

Monitoring dashboards light up.

Operations teams start asking questions.

The Postmortem

After investigation, engineers discover something surprising.

The system isn't struggling because users are sending messages.

The system is struggling because users are asking if there are messages.

Imagine:

200,000 Users

Each user polls every second.

200,000 Requests / Second

Now imagine only 2% of those requests actually contain new information.

That means:

196,000 Requests

exist solely to hear:

"No updates."

Every second.

All day.

Every day.

The servers are spending most of their time answering questions nobody needed to ask.

Looking at the Problem Like an Architect

A junior developer might see:

"Too many requests."

A system architect sees:

"The communication model is wrong."

The real issue wasn't server performance.

The issue was this:

Client
   │
   ▼
Keeps Asking

Even when the server already knows nothing has changed.

The architecture was forcing unnecessary conversations.

A Different Idea

One engineer proposes something unusual.

Instead of:

Client:
Anything new?

Server:
No.

Client:
Anything new?

Server:
No.

What if the conversation became:

Client:
Tell me when something changes.

Server:
Okay. I'll wait.

And that's exactly what Long Polling became.

Long Polling Explained Like a Recruiter

Imagine you're hiring for a company.

Traditional polling looks like this:

Recruiter:
Any new applicants?

System:
No.

Recruiter:
Any new applicants?

System:
No.

Recruiter:
Any new applicants?

System:
No.

Long Polling changes the workflow.

Recruiter:
Call me when somebody applies.

System:
Understood.

Hours later:

New Applicant Submitted
         │
         ▼
Phone Rings

The recruiter isn't constantly checking.

The system notifies them only when something important happens.

That is Long Polling.

What Actually Happens Under the Hood

Let's say a user opens a chat application.

The browser sends:

GET /messages

Normally the server would immediately respond.

With Long Polling:

Request Arrives
       │
       ▼
Server Checks For Updates
       │
       ▼
No Updates Found
       │
       ▼
Keep Connection Open

Now the server waits.

Maybe 5 seconds.

Maybe 20 seconds.

Maybe 60 seconds.

Suddenly:

New Message Arrives

The server immediately responds.

{
  "message": "Hello!"
}

The browser receives the message.

Then instantly creates another waiting request.

Request
  │
Wait
  │
Response
  │
Reconnect
  │
Wait Again

To the user:

It feels instantaneous.

To the infrastructure:

It's still HTTP.

Just used differently.

Why Business Leaders Loved It

From a buyer's perspective, Long Polling created something valuable:

Faster Customer Support

Without Long Polling:

Customer Sends Message
       │
       ▼
Agent Sees It 10 Seconds Later

With Long Polling:

Customer Sends Message
       │
       ▼
Agent Sees It Almost Immediately

Response times improve.

Customer satisfaction improves.

Support metrics improve.

Revenue often improves.

Nobody buying the software cares about Long Polling.

They care that customers stop complaining.

Why Developers Loved It

Because it solved a real problem without requiring a new protocol.

Developers already had:

HTTP
Load Balancers
Reverse Proxies
Application Servers

No major infrastructure changes were needed.

Most teams could implement Long Polling with existing technology.

That made adoption relatively easy.

Why Operations Teams Hated It

Because Long Polling quietly moved pressure somewhere else.

Traditional polling creates:

Many Requests
Short Connections

Long Polling creates:

Fewer Requests
Long-Lived Connections

At first this sounds better.

Until your system reaches:

500,000 Active Users

Now you have:

500,000 Open Connections

waiting simultaneously.

The CPU usage might decrease.

But memory usage increases.

Connection tracking increases.

Load balancer complexity increases.

Timeout management becomes critical.

The bottleneck simply moved.

The Scaling Wall

Around this point, many companies hit a new challenge.

Imagine a global chat application.

1 Million Connected Users

Every user has:

One Waiting Request

Now the infrastructure must remember:

Who is connected
Which request belongs to whom
How long they've been waiting
When to timeout
When to reconnect

The system starts behaving less like a website.

And more like a real-time communication platform.

That distinction becomes important.

Because HTTP was never designed for this.

The Architect's Lesson

Long Polling teaches one of the most important lessons in software architecture.

The first solution that works is rarely the final solution.

The evolution looked like this:

Polling
    │
    ▼
Too Much Waste
    │
    ▼
Long Polling
    │
    ▼
Too Many Open Connections
    │
    ▼
Search For Something Better

Long Polling wasn't the destination.

It was the bridge.

A brilliant compromise between:

User expectations
Existing browser capabilities
Available infrastructure
Engineering constraints

For nearly a decade, some of the largest systems on the internet relied on that compromise.

The Question That Changed Everything

Eventually engineers started asking a different question.

Not:

"How can the client ask more efficiently?"

But:

"Why is the client asking at all?"

What if the connection stayed open permanently?

What if the server could speak first?

What if communication flowed both directions?

That question led to one of the biggest shifts in modern web architecture:

WebSockets.

And that's where our story goes next.

Polling: When "Simple" Starts Sending Millions of Requests

Anik Sikder — Fri, 24 Jul 2026 15:40:20 +0000

Imagine you're building a SaaS platform.

Nothing fancy.

Just a notification bell in the top-right corner.

When someone receives a new message, completes a task, or gets assigned work, the bell should update.

Seems simple, right?

A developer might propose:

Every 5 seconds:

GET /notifications

Done.

Feature shipped.

Customers happy.

Everyone goes home.

For a while.

The Architecture Looks Innocent

With 10 users online, the system behaves exactly as expected.

10 Users
   ↓
GET /notifications
Every 5 seconds

Nobody notices a problem.

The database barely feels the load.

The servers are mostly idle.

The feature appears successful.

This is where many architectural mistakes begin.

Not because the solution is wrong.

But because it works.

Success Changes the Equation

Six months later, your product gains traction.

Now you have:

5,000 active users

The code hasn't changed.

The infrastructure hasn't changed.

The polling interval is still:

Every 5 seconds

But the system is now processing:

5,000 × 12 requests/minute

= 60,000 requests per minute

That's:

3.6 million requests per hour

For a notification system.

Not file uploads.

Not payments.

Not business-critical operations.

Just checking whether something changed.

The Hidden Question

Here's the question experienced engineers ask:

How many of those requests actually matter?

Let's assume only 5% of users receive a notification during a given minute.

That means 95% of requests exist only to discover:

{
  "notifications": []
}

The system is spending CPU, memory, network bandwidth, and database resources simply confirming that nothing happened.

From a business perspective, that's interesting.

Because the company isn't paying for useful work.

It's paying for uncertainty.

Why Companies Still Choose Polling

At this point, many articles declare:

"Polling is bad."

That's the wrong conclusion.

Companies don't buy architectures.

Companies buy outcomes.

Polling remains popular because it optimizes for something businesses care deeply about:

Speed of Delivery

A startup founder rarely asks:

"Is this the most elegant distributed systems solution?"

They ask:

"Can we launch this feature next week?"

Polling is attractive because:

Easy to implement
Easy to debug
Easy to maintain
Works through almost every network and firewall
Requires minimal infrastructure

In other words:

Higher operational cost
↓
Lower development cost

And early-stage companies often prefer that tradeoff.

The Real Architectural Tradeoff

Junior developers often think:

Polling vs WebSockets

Senior engineers think:

Development Cost
vs
Infrastructure Cost
vs
User Experience
vs
Future Scale

Those are completely different conversations.

Every architecture decision is a business decision wearing a technical disguise.

When Polling Becomes Expensive

Imagine your SaaS platform grows to:

100,000 active users

Still polling every 5 seconds.

Now the system receives:

20,000 requests every second

Suddenly:

More application servers
Larger database clusters
Higher cloud bills
More monitoring
More operational complexity

The notification feature itself hasn't become more valuable.

The architecture simply became more expensive.

This is one of the easiest ways successful products accidentally create technical debt.

Not through bad code.

Through successful growth.

The Most Important Lesson

Polling is not a communication pattern.

Polling is an optimization choice.

You're optimizing for:

Simplicity Today

while accepting:

Higher Costs Tomorrow

Sometimes that's exactly the right decision.

Sometimes it's not.

The best engineers aren't the ones who know the newest technologies.

They're the ones who understand the tradeoffs.

And Polling is one of the simplest examples of that principle.

Push vs Pull: A Decision About Where Complexity Lives

Anik Sikder — Tue, 21 Jul 2026 10:52:04 +0000

Most engineers think Push is more advanced than Pull.

It's an easy conclusion to reach.

After all:

Polling feels old.
WebSockets feel modern.
Realtime feels better than waiting.

But some of the largest distributed systems in the world deliberately choose Pull.

Not because Pull is better.

Not because their engineers haven't heard of WebSockets.

Because every distributed system eventually faces a more important question:

Who is responsible for discovering change?

And the answer to that question determines where complexity lives.

At scale, Pull wastes requests.

Push wastes state.

Most architectures are simply deciding which waste is cheaper.

The Real Problem Isn't Communication

Imagine an order is created.

Order Created

Several services care about it:

Inventory Service
Analytics Service
Notification Service
Billing Service

The problem isn't generating information.

The problem is delivering it.

And there are only two fundamental ways to do that.

Pull

Consumers discover changes themselves.

Analytics ----> Order Service
Inventory ----> Order Service
Notification -> Order Service

Each consumer periodically asks:

"Anything new?"

The responsibility belongs to the consumer.

Push

The producer distributes changes.

Order Service
      |
      +----> Analytics
      |
      +----> Inventory
      |
      +----> Notification

The responsibility belongs to the producer.

That's it.

That's the entire Push vs Pull debate.

Polling, Long Polling, SSE, and WebSockets are merely different ways of implementing these two ideas.

Why Pull Refuses to Die

A common misconception among younger engineers is:

Push is the future.

Pull is a legacy workaround.

Reality is less exciting.

Many highly scalable systems intentionally choose Pull.

Kubernetes Is A Great Example

Imagine a Kubernetes cluster containing 10,000 nodes.

Many engineers expect the control plane to constantly push work to nodes.

Instead, nodes continuously ask:

Any new Pods for me?

The nodes pull work.

The control plane doesn't chase them.

Why?

Because Push concentrates responsibility.

Consider the alternative:

Control Plane
      |
      +--> Node 1
      +--> Node 2
      +--> Node 3
      ...
      +--> Node 10,000

Now the control plane must know:

Which nodes are alive
Which nodes are reachable
Which nodes need updates
Which connections failed

Complexity accumulates at the center.

With Pull:

Node 1 ---->
Node 2 ---->
Node 3 ---->
Node N ---->

Each node becomes responsible for its own synchronization.

This is a pattern you'll see repeatedly in distributed systems:

When coordination becomes expensive, systems often shift responsibility to the edges.

Pull tends to distribute complexity.

Polling: The Simplest Pull Strategy

Polling is often mocked because it seems inefficient.

A client repeatedly asks:

Anything new?

Every few seconds.

For example:

GET /orders/123/status

Most responses look identical:

{
  "status": "COOKING"
}

Again.

{
  "status": "COOKING"
}

Again.

{
  "status": "COOKING"
}

Eventually:

{
  "status": "DELIVERED"
}

This creates obvious waste.

Consider:

100,000 clients
poll every 5 seconds

That's:

20,000 requests/sec

even when nothing changes.

Which leads many engineers to conclude:

Polling doesn't scale.

But that's not entirely true.

Polling scales surprisingly well operationally.

Why?

Because stateless systems are easier to operate.

The server receives a request.

Returns a response.

Forgets everything.

No connection state.

No heartbeats.

No reconnection logic.

No presence tracking.

Sometimes infrastructure simplicity is worth more than network efficiency.

The Moment Systems Start Moving Toward Push

The problem with polling isn't that it doesn't work.

The problem is that most requests are useless.

A system designer eventually notices:

Request
No Change

Request
No Change

Request
No Change

Request
Actual Update

We're spending resources discovering nothing.

This realization leads to Long Polling.

Long Polling: Let Me Know When Something Happens

Instead of asking every few seconds:

Anything new?

The client asks:

Tell me when something changes.

The request remains open.

Client ---------------- Server
           waiting...

When an event appears:

New Message

The server responds immediately.

The client opens another request.

This dramatically reduces wasted requests.

The responsibility is still largely Pull-based.

But the behavior begins to resemble Push.

Long Polling became the bridge between traditional request-response systems and modern realtime systems.

SSE: Realtime Without Realtime Infrastructure

Long Polling still has a cost.

After every event:

Connection closes

A new connection must be established.

SSE removes that overhead.

One connection remains open.

Client ------------------------ Server

The server continuously streams updates.

AAPL = 210
AAPL = 211
AAPL = 212

No reconnects.

No repeated requests.

Just a stream.

This is why SSE quietly powers dashboards, monitoring systems, reporting platforms, and internal tooling.

Not because it's flashy.

Because it's operationally boring.

And boring systems are often excellent systems.

Why WebSockets Change Everything

WebSockets introduce a fundamentally different model.

Instead of:

Request
Response

You get:

Client <-----------------> Server

Both sides can communicate whenever they want.

This is essential for:

Chat systems
Multiplayer games
Collaborative editing
Trading platforms

The benefit is obvious:

Event Created
↓
Event Delivered

almost instantly.

Latency becomes tiny.

User experience improves dramatically.

Which is why founders love realtime.

The Cost Nobody Talks About

Most discussions about WebSockets focus on latency.

Experienced architects worry about something else:

State.

Polling wastes requests.

Push systems accumulate state.

A polling server can forget a client immediately after responding.

A WebSocket server cannot.

The server must remember:

User ID
Connection ID
Subscriptions
Heartbeat Status
Presence Information

And it must remember that information continuously.

Now imagine:

10 million connected users

Suddenly you're not managing APIs anymore.

You're managing connections.

And connections become infrastructure.

This is why large realtime companies eventually build:

Connection Gateways
Presence Services
Fanout Systems
Realtime Clusters
Event Brokers

The complexity didn't disappear.

It moved.

The Business Question Behind Push vs Pull

Engineers often evaluate Push and Pull through a technical lens.

Founders and CTOs usually care about a different question:

What will this cost us to operate?

Polling often creates more infrastructure waste.

Push often creates more engineering complexity.

Polling may consume more requests.

Realtime systems may require entire teams dedicated to connection management.

Founders often optimize for user experience.

CTOs often optimize for operational complexity.

Architects spend their careers balancing the two.

How Systems Usually Evolve

Most systems don't start with WebSockets.

They grow into them.

Stage 1
Polling

↓

Stage 2
Long Polling

↓

Stage 3
SSE

↓

Stage 4
WebSockets

↓

Stage 5
WebSockets + Pub/Sub + Fanout Services + Event Infrastructure

This evolution appears repeatedly across the industry.

Not because engineers love complexity.

Because scale eventually demands it.

The Hidden Tradeoff

Most engineers frame the decision like this:

Polling vs WebSockets

System designers frame it differently:

Waste vs State

Polling wastes requests.

Push systems accumulate state.

Pull systems tend to distribute responsibility.

Push systems tend to concentrate responsibility around delivery and state management.

Neither side wins.

Both pay.

The only question is:

Which cost is cheaper for your business?

The Mental Model That Actually Matters

Junior engineers often ask:

Should we use WebSockets?

Senior engineers ask:

Where should complexity live?

Should consumers be responsible for discovering change?

Or should producers be responsible for distributing it?

Because Push vs Pull is not really a networking discussion.

It's a complexity allocation discussion.

And every architecture eventually pays the bill.

The only question is who pays it.

Final Thought

Every Pull system eventually asks:

Why are we wasting so many requests?

Every Push system eventually asks:

Why are we managing so much state?

The goal of architecture is not to eliminate complexity.

The goal is to decide where it lives.