DEV Community

Cover image for Request-Response: The Foundation of Modern APIs
Anik Sikder
Anik Sikder

Posted on • Originally published at aniksikder.hashnode.dev

Request-Response: The Foundation of Modern APIs

#api #backend #distributedsystems #systemdesign

Most developers use Request-Response every day.

Few stop to think about what actually happens after clicking a button.

You open an app.

You tap "Login".

A response appears almost instantly.

Simple, right?

Not exactly.

Behind that seemingly simple interaction lies one of the most important communication patterns in software engineering:

Request-Response.

Whether you're using ChatGPT, ordering food through Uber Eats, checking your bank balance, or watching Netflix, countless Request-Response interactions occur every second.

Understanding this pattern is one of the first steps toward understanding modern backend engineering.

What Is Request-Response?

At its core, Request-Response is a conversation between two systems.

One system asks for something.

Another system answers.

Client                    Server
   |                         |
   |------ Request --------->|
   |                         |
   |<----- Response ---------|
   |                         |
Enter fullscreen mode Exit fullscreen mode

The client initiates communication.

The server processes the request and returns a response.

This interaction is typically short-lived and synchronous.

The client sends a request and waits for an answer.

A Real-World Analogy

Imagine you're sitting in a restaurant.

You call the waiter.

Customer -> "I'd like a burger."
Enter fullscreen mode Exit fullscreen mode

The waiter takes your order to the kitchen.

The kitchen prepares the meal.

The waiter returns with your food.

Kitchen -> "Here's your burger."
Enter fullscreen mode Exit fullscreen mode

That's Request-Response.

Customer = Client
Waiter = Network
Kitchen = Server
Burger = Response
Enter fullscreen mode Exit fullscreen mode

Most web applications operate using exactly this pattern.

The Journey of a Request

Consider a simple login request.

POST /login
Enter fullscreen mode Exit fullscreen mode

It may look simple from the browser's perspective.

But internally:

Browser
   |
Load Balancer
   |
API Gateway
   |
Authentication Service
   |
Database
Enter fullscreen mode Exit fullscreen mode

The response must travel back through the same chain.

Database
   |
Authentication Service
   |
API Gateway
   |
Load Balancer
   |
Browser
Enter fullscreen mode Exit fullscreen mode

Every step introduces latency, failure possibilities, and complexity.

Latency: The Hidden Cost of Distance

Latency is the time required for a request to travel through the system and return a response.

Request Sent --------------------->

<-------------------- Response Received
Enter fullscreen mode Exit fullscreen mode

Users don't care about architecture diagrams.

They care about speed.

When someone clicks a button, they expect a response immediately.

Even small delays are noticeable.

Typical user perception:

Response Time User Experience
0–100 ms Instant
100–300 ms Fast
300–1000 ms Noticeable
1–3 sec Slow
3+ sec Frustrating

At scale, reducing latency becomes a competitive advantage.

This is one reason companies invest heavily in:

  • CDNs

  • Caching

  • Edge Computing

  • Database Optimization

  • Load Balancing

Timeouts: Waiting Forever Is Not an Option

Imagine calling a restaurant and nobody answers.

How long should you wait?

Five seconds?

Five minutes?

An hour?

Software faces the same problem.

A timeout defines the maximum amount of time a system is willing to wait for a response.

Client ---- Request ---->
                ...
                ...
                ...
Timeout Reached
Enter fullscreen mode Exit fullscreen mode

Without timeouts, systems can become stuck waiting forever.

This leads to:

  • Hanging requests

  • Resource exhaustion

  • Poor user experience

Every production-grade system uses timeouts.

Retries: What If the Request Fails?

Networks are imperfect.

Packets get lost.

Servers restart.

Databases become temporarily unavailable.

A single failure doesn't necessarily mean the operation should fail.

Instead, many systems retry.

Attempt #1 -> Failed

Attempt #2 -> Failed

Attempt #3 -> Success
Enter fullscreen mode Exit fullscreen mode

Retries improve reliability.

But they also introduce a dangerous problem.

What if the original request actually succeeded?

Idempotency: Preventing Duplicate Operations

Imagine clicking:

Pay Now
Enter fullscreen mode Exit fullscreen mode

The payment succeeds.

But the response never reaches your browser.

Your application thinks the request failed.

It retries.

Charge Card
Enter fullscreen mode Exit fullscreen mode

Again.

Without protection, the customer could be charged twice.

This is why payment systems use idempotency.

An idempotent operation produces the same result even if executed multiple times.

Request ID: abc123
Enter fullscreen mode Exit fullscreen mode

If the same request arrives again:

Request ID: abc123
Enter fullscreen mode Exit fullscreen mode

The server recognizes it and returns the previous result instead of processing the payment again.

This concept is critical in systems like:

  • Stripe

  • PayPal

  • Banking Platforms

  • Order Processing Systems

Fan-Out: One Request Can Become Many

A request rarely stays simple for long.

Imagine opening a product page.

The backend may need:

Product Service
Review Service
Inventory Service
Pricing Service
Recommendation Service
Enter fullscreen mode Exit fullscreen mode

One incoming request becomes many downstream requests.

                 Product
                /
Client ---- API Gateway
                \
                 Reviews

                 Inventory

                 Pricing
Enter fullscreen mode Exit fullscreen mode

This pattern is called Fan-Out.

Fan-Out increases functionality.

But it also increases risk.

If one dependency becomes slow, the entire response can become slow.

Cascading Failures

Now imagine the Review Service becomes overloaded.

Requests begin timing out.

The Product Service waits.

Threads become blocked.

Connection pools fill up.

More requests pile up.

Soon:

Review Service Failure
        |
        v
Product Service Slow
        |
        v
API Gateway Slow
        |
        v
Entire Application Slow
Enter fullscreen mode Exit fullscreen mode

A small issue spreads throughout the system.

This is called a Cascading Failure.

Many major outages start exactly this way.

A single dependency struggles.

Everything connected to it suffers.

Observability: Seeing What the System Sees

When users complain:

"The app feels slow."

Where exactly is the problem?

The database?

The cache?

The network?

The payment service?

Without visibility, debugging becomes guesswork.

Modern systems rely on observability.

Three pillars are commonly used:

Logs

Individual events.

User logged in
Payment created
Order shipped
Enter fullscreen mode Exit fullscreen mode

Metrics

System health measurements.

CPU Usage
Memory Usage
Request Rate
Error Rate
Latency
Enter fullscreen mode Exit fullscreen mode

Traces

The complete journey of a request.

Client
  -> Gateway
     -> Auth Service
        -> Database
Enter fullscreen mode Exit fullscreen mode

Tracing reveals where time is spent.

At scale, observability becomes essential.

Why Request-Response Eventually Becomes a Bottleneck

Request-Response is simple.

That's its greatest strength.

But it's also its limitation.

The client must wait.

Request --->

<--- Response
Enter fullscreen mode Exit fullscreen mode

No response means no progress.

As systems grow, engineers begin exploring alternatives:

  • Polling

  • Long Polling

  • Server-Sent Events (SSE)

  • WebSockets

  • Pub/Sub

  • Event-Driven Architectures

These patterns exist because traditional Request-Response is not always enough.

But every one of them builds upon the foundation established by Request-Response.

Final Thoughts

Request-Response appears deceptively simple.

A client asks.

A server answers.

Yet hidden beneath that simplicity are some of the most important challenges in software engineering:

  • Latency

  • Timeouts

  • Retries

  • Idempotency

  • Fan-Out

  • Cascading Failures

  • Observability

Understanding these concepts is what separates someone who can build APIs from someone who can design reliable systems.

Before learning WebSockets, Event Streaming, or Distributed Systems, it's worth mastering the communication pattern that powers nearly every application on the internet:

Request-Response.

Top comments (0)