Senior scalability interview questions and answers covering horizontal scaling, vertical scaling, load balancing, stateless services, caching, database bottlenecks, queues, backpressure, autoscaling, hot keys and capacity planning

Scalability interview questions for Senior backend engineers are rarely about defining horizontal scaling. The difficult questions begin when an interviewer says traffic will grow from 1,000 requests per second to 100,000, adding application instances stops improving throughput, one customer generates 30% of all traffic, or autoscaling creates more pods while the database becomes progressively slower.

Senior engineers need to understand that scalability is an end-to-end property. Scaling the application tier does not automatically scale PostgreSQL, Redis, Kafka, third-party APIs, network bandwidth, or the business workflow itself. The strongest system design answers identify the first constrained resource, quantify the workload, and introduce complexity only where the existing architecture actually reaches its limit.

1. What Does It Mean for a Backend System to Be Scalable?

A scalable system can accommodate meaningful workload growth without requiring disproportionate increases in cost, latency, operational complexity, or failure risk.

But “scale” needs a dimension.

The workload might grow in:

Requests per second
Concurrent users
Writes per second
Dataset size
Events per second
Geographic regions
Tenants
Background jobs

An architecture capable of serving enormous read traffic may perform poorly under write-heavy workloads.

Before discussing scalability, I define what is growing. Otherwise “design this to scale” is too vague to drive an architecture.

2. Vertical Scaling or Horizontal Scaling?

Vertical scaling means giving an existing machine more resources:

8 CPU → 32 CPU
32 GB RAM → 128 GB RAM

Horizontal scaling adds additional machines or instances:

1 instance → 10 instances

Vertical scaling is operationally simple and can be surprisingly effective, particularly for systems that are difficult to distribute.

Horizontal scaling can provide higher aggregate capacity and different failure characteristics, but it introduces load balancing, distributed state, coordination, deployment, observability, and consistency concerns.

I do not choose horizontal scaling merely because it sounds more sophisticated. I choose the simplest model that meets the expected workload and availability requirements.

3. What Makes an Application Easy to Scale Horizontally?

Stateless request processing makes horizontal scaling significantly easier.

If every instance can process any request:

┌→ Instance A
Client → LB ├→ Instance B
            └→ Instance C

the load balancer can distribute traffic without needing to know which server handled a user’s previous request.

Problems appear when critical session or workflow state exists only in one instance’s memory:

User session → Instance B memory

If the next request reaches Instance C, that state may be unavailable.

State can instead live in an appropriate shared or durable system, depending on the requirements. The goal is not “never use local memory,” but avoiding accidental correctness dependencies on one application instance.

4. You Added Ten Application Instances but Throughput Barely Improved. Why?

Because the application tier may not be the bottleneck.

Imagine:

10 app instances
      ↓
PostgreSQL

If PostgreSQL already reaches its sustainable capacity, adding another 20 application instances creates more clients competing for the same constrained database.

The same problem can occur with:

Redis
Kafka partitions
External APIs
Storage
Network bandwidth
Connection pools
Locks

Horizontal scaling works when the component being replicated is the limiting resource or when additional instances can access enough downstream capacity.

The first question should therefore be: what resource prevents throughput from increasing?

5. How Does a Load Balancer Help Scalability?

A load balancer distributes incoming traffic across multiple service instances.

At a simple level:

┌→ App 1
Requests → LB → App 2
            └→ App 3

but distribution quality matters.

Round-robin may work well when requests have similar cost. If some requests take 20 milliseconds while others run for 20 seconds, equal request counts do not necessarily mean equal load.

Load balancers can also participate in health checking, connection management, TLS termination, geographic routing, or other responsibilities depending on the architecture.

A load balancer enables horizontal distribution; it does not guarantee that work is distributed efficiently.

6. What Is a Scalability Bottleneck?

A bottleneck is the resource whose capacity currently limits the system’s useful throughput.

Suppose the request path is:

Load Balancer
     ↓
Spring Boot
     ↓
Redis
     ↓
PostgreSQL

and the capacities are approximately:

App tier     → 100k req/sec
Redis        → sufficient for workload
PostgreSQL   → 12k relevant operations/sec

Scaling the app tier beyond what is required to drive PostgreSQL to capacity will not meaningfully improve end-to-end throughput.

The bottleneck can also move. After optimizing PostgreSQL, CPU may become limiting. After scaling CPU, an external API may become the next constraint.

Scalability engineering is often the repeated process of finding the next limiting resource.

7. How Would You Scale a Read-Heavy System?

I first inspect why reads are expensive.

Potential mechanisms include:

Indexes
Caching
Read replicas
Precomputed views
Search indexes
CDNs
Denormalized read models

The right mechanism depends on the data.

Static public assets are very different from account balances. Product descriptions may tolerate caching, while a correctness-sensitive financial state may require stronger freshness guarantees.

I also consider the read-to-write ratio. A system receiving 100,000 reads and 500 writes per second has different scaling opportunities from one receiving 50,000 writes per second.

Read scaling is often easier precisely because some read workloads can be replicated or cached.

8. How Would You Scale a Write-Heavy System?

Write scaling is generally harder because writes modify authoritative state and frequently require coordination.

Before sharding, I would investigate whether unnecessary writes exist, whether operations can be batched, whether indexes are making writes more expensive, and whether all writes truly require synchronous processing.

Some workloads can use asynchronous ingestion:

Request
   ↓
Durable queue/log
   ↓
Workers
   ↓
Storage

but that changes consistency and completion semantics.

At sufficiently large scale, partitioning or sharding may distribute write ownership. That introduces shard-key selection, rebalancing, hot partitions, and cross-shard operation complexity.

Write scaling should therefore begin with workload semantics, not automatically with “add Kafka.”

9. How Can Caching Improve Scalability?

Caching can prevent repeated computation or database access for frequently reused data.

Without a cache:

100k requests
     ↓
Database

With a high-value cache:

100k requests
     ↓
Cache
 ┌───┴───┐
hits    misses
         ↓
      Database

If the hit ratio is high and the workload is suitable, database demand can decrease dramatically.

But caching introduces invalidation, stale data, eviction, memory limits, stampedes, and failure-mode questions.

The most important scalability question is what happens when the cache disappears. If the database cannot survive the resulting miss traffic, the cache has become part of the system’s capacity architecture.

10. What Is a Hot Key?

A hot key receives a disproportionate amount of traffic.

Suppose Redis stores millions of keys, but one celebrity profile or globally shared configuration key receives 25% of all reads.

Data may be evenly distributed while traffic is not:

Key A → 25%
Remaining millions of keys → 75%

That one key can saturate a node, partition, network path, or application synchronization mechanism.

Possible responses depend on the system and can include local caching, replication, request coalescing, partition-aware techniques, or changing the data-access model.

Scalability must consider access skew, not only total dataset size.

11. What Is a Hot Partition?

A hot partition occurs when one partition receives much more work than the others.

Imagine Kafka events partitioned by:

customerId

and one enormous customer produces 40% of all events.

Adding more consumers may not help because events for that key continue to map to the same partition.

A similar problem occurs in sharded databases when one shard receives disproportionate reads or writes.

Partition count alone does not guarantee parallelism. Effective scalability depends on workload distribution across those partitions.

12. How Can a Queue Improve Scalability?

A queue can decouple the rate at which work arrives from the rate at which workers process it.

Suppose traffic occasionally spikes:

Normal: 5k jobs/sec
Spike: 20k jobs/sec
Worker capacity: 8k/sec

A durable queue can absorb a temporary burst while workers process the backlog.

This is useful when work does not need to complete synchronously.

But a queue does not create processing capacity. If incoming traffic remains at 20k/sec while consumers can sustain only 8k/sec, backlog grows indefinitely.

Queues absorb bursts. They do not solve permanent capacity deficits.

13. What Is Backpressure?

Backpressure prevents upstream producers from overwhelming slower downstream consumers.

Without it:

Producer: 50k/sec
Consumer: 10k/sec
Backlog: +40k/sec

The system can accumulate huge queues, memory pressure, latency, or retry traffic.

Backpressure can appear through bounded queues, concurrency limits, flow control, admission control, or explicit rejection depending on the architecture.

The important concept is that capacity information must eventually travel upstream.

A system that accepts unlimited work despite finite processing capacity is not infinitely scalable. It is postponing the failure.

14. When Does Autoscaling Fail to Solve the Problem?

Autoscaling helps when adding instances increases useful capacity.

Suppose application CPU rises and each additional pod can independently process more work. Scaling on an appropriate signal may work well.

Now consider:

10 pods → PostgreSQL saturated
20 pods → same PostgreSQL
40 pods → same PostgreSQL

Autoscaling the application can increase connection demand and make the database problem worse.

The same applies to external APIs with fixed quotas or Kafka workloads constrained by partition parallelism.

Autoscaling should therefore respond to a bottleneck that can actually be relieved by adding replicas.

15. How Would You Scale a System From 1,000 to 100,000 Requests per Second?

I would not begin by drawing 100 microservices.

First I would quantify the workload:

Read/write ratio
Payload size
Database operations/request
Cacheability
Latency target
Traffic distribution
Peak/average ratio
Geographic distribution
Consistency requirements

Then I would load test the simplest architecture and identify its first bottleneck.

A possible evolution might be:

Single service
      ↓
Multiple stateless instances
      ↓
Caching
      ↓
Read scaling
      ↓
Async processing
      ↓
Workload separation
      ↓
Partitioning where required

The exact sequence depends on measured constraints.

Good scalability architecture evolves around evidence rather than predictions about problems that may never exist.

How Do You Estimate Capacity Before Building the System?

Back-of-the-envelope estimation is useful because it turns vague scale into engineering quantities.

Suppose:

10 million daily active users
20 requests/user/day

That is:

200 million requests/day

Dividing by 86,400 gives roughly:

~2,315 requests/sec average

But average traffic is rarely enough. If peak traffic is five times average:

~11,600 requests/sec peak

Then I estimate reads, writes, payload sizes, storage growth, cache demand, and downstream operations.

The numbers do not need to predict production perfectly. Their purpose is to reveal whether we are designing for thousands, hundreds of thousands, or millions of operations per second.

Why Is Average Traffic Misleading?

A service receiving one billion requests per month may sound enormous, but monthly averages hide traffic distribution.

A system may experience:

Average → 5k req/sec
Normal peak → 20k req/sec
Launch event → 80k req/sec

Capacity needs to handle meaningful peaks, not only averages.

I also consider burst duration. A 100k req/sec spike lasting two seconds can sometimes be absorbed differently from the same rate sustained for six hours.

Scalability planning requires both magnitude and time.

What Is Headroom?

Running every system continuously at 100% sustainable capacity leaves almost no ability to absorb traffic spikes, failures, deployments, or uneven load.

Suppose a fleet normally operates at 95% capacity and one availability zone loses instances. Remaining capacity may immediately become insufficient.

Operational systems therefore often need headroom.

The exact amount depends on architecture, failure requirements, scaling speed, traffic volatility, and cost constraints.

Headroom is not wasted capacity by definition. It can be part of the reliability budget.

Why Does p99 Latency Often Get Worse Before Average Latency?

As utilization increases, some requests begin experiencing queueing or contention before the entire workload is equally affected.

You might observe:

p50 → 80 ms
p95 → 150 ms
p99 → 2.5 sec

while average latency still appears acceptable.

Tail latency can therefore provide an early signal of saturation, hot partitions, slow queries, lock contention, GC pauses, or uneven instances.

At scale, a small percentage of requests still represents many users.

I would investigate the slow population rather than relying on fleet-wide averages.

What Is the Relationship Between Latency and Concurrency?

A useful intuition comes from Little’s Law:

L = λW

If throughput remains constant but each request takes longer, the number of requests simultaneously present in the system increases.

Suppose a service handles:

5,000 req/sec

and average request duration increases from 100 milliseconds to one second.

The system now has roughly ten times as much concurrent work in flight under the simplified model.

That additional concurrency consumes threads, connections, memory, and queue capacity.

Latency degradation can therefore become resource exhaustion even when incoming request rate does not change.

Why Can One Large Customer Break a Multi-Tenant System?

Average customer behavior can hide extreme tenants.

Suppose 10,000 customers generate relatively small workloads while one enterprise tenant generates:

30% of writes
40% of storage
25% of expensive reports

Shared resources may become dominated by that tenant.

Possible strategies include per-tenant rate limits, quotas, workload isolation, dedicated partitions, separate worker pools, or dedicated infrastructure for exceptional customers.

The right solution depends on economics and isolation requirements.

Multi-tenant scalability is partly about fairness, not just aggregate capacity.

When Should You Denormalize Data for Scalability?

Normalization provides important consistency and maintainability benefits, but some high-volume read patterns can require repeated joins or expensive aggregations.

A dedicated read model might store data closer to the shape required by the query:

Transactional model
      ↓
Events / processing
      ↓
Denormalized read model

This can reduce read-time computation at the cost of additional storage, synchronization logic, and potentially eventual consistency.

I would denormalize because a measured access pattern justifies it, not because “NoSQL scales better.”

Every duplicate representation creates another consistency responsibility.

When Should You Precompute Results?

If the same expensive calculation is requested repeatedly and its inputs do not change continuously, computing it once may be cheaper than recalculating it for every request.

For example:

Expensive aggregation
      ↓
Precompute periodically
      ↓
Serve cheap reads

The trade-off is freshness.

A dashboard that can be five minutes stale may be a strong candidate. A payment balance requiring immediate correctness may not be.

Scalability often comes from moving work away from the critical request path, but the business must permit the resulting consistency model.

How Does Asynchronous Processing Improve Scalability?

Synchronous processing requires the caller to remain connected while every required operation completes.

If some work can happen later:

Request
   ↓
Persist intent
   ↓
Return
   ↓
Async workers

the synchronous request path becomes shorter and background processing can scale independently.

This can work well for emails, media processing, analytics, some exports, and other non-immediate workflows.

However, asynchronous processing introduces job state, retries, duplicate handling, observability, failure recovery, and user-facing completion semantics.

Moving work to a queue does not remove complexity. It moves the complexity into workflow management.

How Do You Know When to Split a Service?

I do not split a service simply because traffic increased.

If one application can scale horizontally and its database and deployment model remain healthy, a larger service can still scale effectively.

A split becomes more interesting when workloads have materially different:

Scaling characteristics
Ownership
Failure domains
Deployment cadence
Data boundaries
Resource profiles

For example, CPU-intensive video processing may benefit from independent scaling from a lightweight account API.

Service decomposition should create useful boundaries. Splitting code without removing shared bottlenecks can produce a distributed monolith with the same scalability constraints.

What Should You Monitor to Detect Scalability Limits?

I want saturation signals across the entire request path:

Request rate
p50 / p95 / p99 latency
CPU
Memory
Thread utilization
Executor queues
Connection pools
Database latency
Replication lag
Cache hit ratio
Queue lag
Partition skew
Error rate
External API latency

Capacity dashboards should also preserve dimensions such as instance, tenant, shard, partition, endpoint, and region.

Fleet-wide averages can hide one overloaded shard or one pathological tenant.

Scalability problems are often distribution problems, so observability needs to show distribution.

How Would You Load Test a System?

I would model realistic workload characteristics rather than sending the easiest possible request as fast as possible.

The test should reflect:

Read/write mix
Payload distribution
Hot keys
Tenant distribution
Authentication
Database state
Cache hit/miss behavior
External dependencies
Burst patterns

I would increase load gradually and observe where latency, errors, or resource saturation begin changing non-linearly.

The most valuable output is often not “the system handled 50k RPS.” It is discovering which resource becomes constrained first and how the system behaves after reaching that point.

A good load test explores failure, not only the highest successful number.

How I Answer Scalability Questions in Senior Interviews

I use four steps:

1. Quantify workload
2. Identify bottleneck
3. Scale that bottleneck
4. Explain the new trade-off

If reads dominate, caching or replication may help. If writes dominate, I investigate write amplification, batching, asynchronous workflows, and eventually partitioning. If CPU dominates, application replicas may help. If one dependency is saturated, scaling unrelated components will not.

Then I explain what the proposed solution introduces: stale reads, invalidation, operational complexity, ordering constraints, partition skew, or additional failure modes.

Senior scalability answers should show restraint as well as technical breadth.

What Interviewers Are Actually Testing

Scalability interview questions are not testing how many distributed-system technologies you can fit onto a whiteboard.

They are testing whether you understand where capacity comes from.

A load balancer does not create database throughput. Ten Spring Boot instances do not make one saturated PostgreSQL server ten times faster. Kafka does not create consumer capacity. Redis does not eliminate the need for database fallback capacity, and autoscaling does not help when every new instance competes for the same exhausted dependency.

The strongest Senior engineer begins with workload numbers, finds the first constrained resource, scales only where necessary, and understands that every scalability mechanism creates another operational trade-off.

That is how systems grow without becoming unnecessarily distributed before the traffic requires it.

Go Deeper

I built System Design Interview Trade-Offs for engineers preparing for Senior backend and system design interviews involving scalability, caching, databases, queues, consistency, replication, sharding and distributed-system architecture.

Senior System Design Interview Playbook: Architecture Trade-Offs, Scaling & Failure Modes

I also publish practical engineering notes on scalability, backend architecture, distributed systems and system design on Substack:

Devrim's's Substack | Substack

Scalability Interview Questions: 15 Questions Senior Backend Engineers Should Be Able to Answer was originally published in JS Decoded in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you push a little further, the best answer you’ll usually get is that it’s simply a way for two systems to communicate.

Fair enough. But if you’re honest with yourself, that answer probably left you thinking, “Yeah, I already knew that.”

So today, let’s break API down in a really simple way — the kind of way that actually sticks.

Before you can understand API, you need to understand one word: Interface.

Every time you hear “interface,” just think of it as a door. That’s it. Nothing more complicated than that.

Now let’s pause on that thought for a second, and go somewhere unexpected, inside your own computer to see exactly how that door (interface) works in real life.

How does a computer actually get things done?

Imagine three apps running on your machine right now: a Node.js app, a Python app, and a PHP app.

• The Node.js app wants to write a file.
• The Python app wants to read a file.
• The PHP app wants to open a file.

All three of these apps run in what’s called user mode. And here’s the key rule of user mode: none of these apps are allowed to directly touch your hardware. Not the CPU, not the RAM, not the disk. No exceptions.

So what do they do instead? Each app sends its request to something called the System Call Interface.

Notice that word again — interface. It’s simply the door every app’s request has to pass through.

From there, the System Call Interface hands the request to the Instruction Set Architecture (ISA) — the set of low-level instructions your hardware actually understands.

The ISA then talks to the hardware components — CPU, RAM, disk — and the real work finally happens.

Once that work is done, the response doesn’t just appear back in your app magically. It travels back the same way it came: from the hardware, back through the System Call Interface and only then does it land back in your app.

Wait — why can’t apps just access the hardware directly?

Good question, and it’s worth stopping on.

If every app could touch the hardware directly, there would be no control at all. A careless app could overwrite memory another app is using. A buggy app could corrupt your disk. One process could freeze your entire machine, and nothing would stop it.

The System Call Interface exists so that every request gets checked before it’s allowed to actually happen. It’s not there to slow things down, it’s there to make sure nothing gets in without permission.

That’s the whole job of an interface: a checkpoint that decides what’s allowed through, and what isn’t.

Now let’s come back to “interface” — with fresh eyes

You’ve just seen how a computer performs an operation. Now let’s map that exact same idea onto something you already work with every day.

Think of your application — Node.js, Python as the client: a browser, or something like Postman. Earlier, Node.js, Python, and PHP were the ones sending requests. Now think of the client — a browser, or something like Postman playing that same role.

Think of the System Call Interface as your Interface.

And think of the hardware as your actual server, the place where the real work happens.

When a client sends a request, it doesn’t land straight in your server. It arrives at the interface first. And just like the System Call Interface checked things before letting a request through, your interface checks its own set of things:

• What resource is this request about — /users, /products/:id, /orders/:id?
• What method is being used — GET, POST, PUT, DELETE?
• Based on that resource and method, which controller or function should actually handle it?
• Does this request even have the permission to do what it’s asking?

Only after all of that is confirmed does the request actually reach your server logic and get processed.

Why can’t a client access the server directly?

For the exact same reason your Node.js, Python, or PHP app can’t directly access the hardware.

If a client could skip the interface and talk to your server directly, there would be no checkpoint to stop it. Nothing would verify whether that client is even allowed to read that data, let alone change it. One request could quietly do damage another request was never supposed to be able to do.

The interface exists to be that checkpoint — deciding, request by request, what’s allowed to actually reach your server, and what gets stopped right at the door.

So why do we call it “Application Programming Interface”?

Because that’s exactly what it is. It’s an interface — a door, a checkpoint — and it exists specifically to handle requests for an application, programmatically, through code.

Take away any one of those three words, and the name stops making sense. Put them together, and you get exactly what you’ve just seen: a controlled door, sitting in front of your application, deciding what gets in.

That’s it. That’s an API.

The Door Nobody Talks About: What API Really Means was originally published in JS Decoded in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this post, I’ll share 10 crazy JavaScript behaviors that most developers don’t know. These are perfect for impressing your team or just scratching your brain.

1. Functions Are Objects

Most developers know functions can be called, but did you know they are actually objects too?

function greet() {}
greet.message = "Hello World!";
console.log(greet.message); // "Hello World!"

Yep, you can literally store properties on a function like any other object. JS is flexible… maybe too flexible.

2. Sorting Numbers

If you try to sort numbers without a compare function, JS will sort them as strings:

console.log([10, 2, 30].sort()); // [10, 2, 30] 😱

Always remember to pass a compare function for numbers:

[10,2,30].sort((a,b) => a-b);

3. Mind-Bending Type Coercion

JavaScript loves to coerce types in weird ways:

console.log(+[]);    // 0
console.log(+![]);   // 1
console.log([] == ![]); // true 😵

Yes, these are valid JavaScript expressions. Don’t let your brain explode… yet.

4. Array Holes Are Strange

let arr = [];
arr[2] = "hi";
console.log(arr.length); // 3
console.log(arr);        // [ <2 empty items>, 'hi' ]
console.log(arr.map(x => x || 0)); // [0, 0, "hi"]

Notice the first and second index? It’s an “empty slot” — it doesn’t exist in memory but still counts in the array’s length.

5. Strings Are Array-Like, But Immutable

let str = "hello";
console.log(str[0]); // "h"
str[0] = "H";
console.log(str); // "hello" (still unchanged)

Strings are immutable — so if you want to change them, you need to create a new string.

6. Floating-Point Madness

console.log(0.1 + 0.2 === 0.3); // false
console.log(0.1 + 0.2);         // 0.30000000000000004

JavaScript numbers aren’t perfect — floating-point math can be slightly off. Always watch out!

7. NaN is the only value not equal to itself

console.log(NaN === NaN); // false
console.log(Object.is(NaN, NaN)); // true

NaN represents an undefined or unrepresentable number, so it’s intentionally not equal to anything, including itself.

8. Emoji Variable Names Are Legal

const 😎 = () => "cool";
console.log(😎()); // "cool"

JavaScript allows Unicode characters as variable and function names. Emoji coding, anyone?

9. Everything Can Be Truthy or Falsy

console.log(Boolean({})); // true
console.log(Boolean([])); // true
console.log(Boolean(new Boolean(false))); // true

Even new Boolean(false) is truthy. JavaScript has a very flexible (and sometimes confusing) truthiness system.

10. Negative zero exists

console.log(0 === -0); // true
console.log(1 / 0);    // Infinity
console.log(1 / -0);   // -Infinity

JavaScript distinguishes -0 from 0, though most operations treat them the same.

Wrapping Up

JavaScript is quirky, fun, and occasionally maddening. Once you start exploring these odd behaviors, you start seeing the language in a whole new light.

If you enjoyed these tricks, try them out in your own projects and see how many of your friends will go “Wait… that’s valid JS?!”

JavaScript Weirdness You Didn’t Know Existed was originally published in JS Decoded in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Server-Side Request Forgery (SSRF) is one of the most dangerous and misunderstood vulnerabilities in modern web applications.
Most Node.js SSRF “solutions” rely on **regex**, **blacklists**, or **string checks** — and attackers bypass them easily.

So I built **dssrf**, a safe‑by‑construction SSRF defense library for Node.js that focuses on *eliminating entire bug classes*, not patching individual payloads.

**GitHub:** https://github.com/HackingRepo/dssrf-js
**npm:** https://www.npmjs.com/package/dssrf

— -

# Why SSRF Is Harder Than Developers Think

Most SSRF bypasses come from things developers don’t expect:

- DNS rebinding
- Redirect chains
- IPv6 edge cases
- Encoded IPs
- Unicode tricks
- URL normalization inconsistencies
- Alternative IP formats
- Cloud metadata endpoints

A simple blacklist like:

```js
if (url.includes(“localhost”)) reject();
```

…is not enough. Attackers can bypass it with:

http://127.1/

http://2130706433/

http://[::ffff:127.0.0.1]/

http://google.com@127.0.0.1/

http://google.com%00@127.0.0.1/

What dssrf Does Differently?

Instead of blacklists, dssrf uses a multi‑step, safe‑by‑construction approach:

- URL normalization (RFC‑correct)
 — Unicode normalization

- Backslash to slash conversion

- Credential stripping

- Scheme validation

- Canonicalization

- DNS resolution + IP classification
 — Detects internal IPs

- Detects cloud metadata IPs

- Detects IPv6 local addresses

- Detects IPv4/IPv6 rebinding

- Redirect chain validation
 — Every redirect target is validated with the same rules.

- Protocol restrictions
 — Only http and https are allowed.

- TypeScript types included
 — Full .d.ts support for modern Node.js projects.

Introducing dssrf: A Safe‑by‑Construction SSRF Defense Library for Node.js was originally published in JS Decoded in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.