DDoS Attacks Explained for Developers: How They Work and What They Break

Your application can be healthy and still become unreachable.

The latest deployment may be fine. Your database may still be running. Your application processes may not have crashed.

Yet users suddenly start seeing timeouts, connection failures, unusually high latency, or 5xx errors.

One possible explanation is that a distributed denial-of-service attack is crowding out legitimate requests.

For developers, SREs, DevOps teams, and anyone responsible for an internet-facing application, it helps to understand DDoS attacks in terms of one simple question:

Which finite resource is the attacker trying to exhaust?

That resource could be bandwidth. It could be TCP connection state. It could be CPU, memory, database connections, or application-processing capacity.

Once you look at DDoS this way, the different attack types become much easier to understand.

TL;DR

A Distributed Denial of Service (DDoS) attack sends traffic or requests from multiple distributed sources toward the same website, server, API, network, or application.

The objective is usually not to break into the system. It is to consume enough available capacity that legitimate users can no longer use the service normally.

There are three broad categories:

Attack type	What it tries to exhaust	Examples
Volumetric	Network bandwidth	UDP floods, DNS amplification
Protocol	Connection and network-device resources	SYN floods, ACK floods
Application layer	Application and backend resources	HTTP floods, Slowloris

A real campaign can use more than one of these at the same time.

What actually happens during a DDoS attack?

Imagine an API that normally handles 10,000 requests per second comfortably.

Under legitimate load, the requests are distributed across endpoints, users, sessions, and normal usage patterns.

Now imagine hundreds of thousands of machines—or reflected third-party services—begin sending traffic toward that API or the infrastructure in front of it.

The attack generally follows a pattern like this:

1. Distributed traffic sources are assembled

Attackers can use compromised computers, routers, IoT devices, cloud systems, or other internet-connected machines.

A collection of compromised devices under remote control is commonly called a botnet.

Attackers can also use reflection attacks. Instead of sending all traffic directly, they cause third-party services to send responses toward the victim.

2. A target is selected

The target could be:

• a domain
• an IP address
• a web application
• an API endpoint
• a DNS service
• a game service
• a TCP or UDP service

Attackers may also change targets during a campaign.

3. Traffic arrives at scale

The distributed systems begin generating packets, connections, or application requests.

At this point, the question becomes:

Where does the bottleneck appear first?

4. A finite resource is exhausted

Depending on the attack, the target may run short of:

• network bandwidth
• connection-table capacity
• CPU
• memory
• worker processes
• database connections
• application threads
• upstream service capacity

Legitimate traffic now competes with malicious traffic for the same resources.

The result can be increased latency, connection failures, application errors, or complete service unavailability.

The three DDoS categories developers should know

1. Volumetric attacks: overwhelm the pipe

A volumetric DDoS attack aims to consume available network capacity.

Think of this as filling the road before legitimate traffic can even reach your application.

Typical examples include:

• UDP floods
• ICMP floods
• DNS amplification
• NTP amplification

From an application perspective, this can be frustrating because your origin may technically still be healthy.

It simply becomes difficult or impossible to reach.

These attacks are commonly discussed in bits per second (bps) because the amount of network traffic itself is central to the attack.

2. Protocol attacks: exhaust connection-handling resources

Protocol attacks focus more on how networking systems maintain connections or process packets.

A classic example is the SYN flood.

Normally, establishing a TCP connection involves a handshake. A SYN flood creates large numbers of connection attempts without allowing the normal process to complete.

Enough unfinished connections can consume finite connection-handling resources.

Other examples include:

• ACK floods
• TCP floods
• fragmentation attacks

These attacks are often measured in packets per second (pps).

3. Application-layer attacks: make the application work

This is often the most interesting category from a developer perspective.

An application-layer, or Layer 7, attack can send HTTP requests that look technically valid.

Instead of simply throwing enormous amounts of bandwidth at the target, the attacker may repeatedly request operations that are expensive for the application.

Consider endpoints such as:

POST /login
GET /search?q=...
POST /checkout
GET /api/reports

A single request might be harmless.

But what if each request triggers several downstream operations?

HTTP request
    ↓
Authentication check
    ↓
Application logic
    ↓
Database query
    ↓
Cache lookup
    ↓
Third-party/API call
    ↓
Response

Now multiply that work across a large number of malicious requests.

An attacker can create significant backend pressure without generating the same raw bandwidth as a volumetric attack.

Typical application-layer examples include:

• HTTP GET floods
• HTTP POST floods
• Slowloris-style attacks
• attacks targeting login or search functions
• attacks targeting expensive API endpoints

These attacks are commonly discussed in requests per second (rps).

Why Layer 7 attacks can be difficult to spot

Blocking obviously malformed traffic is one thing.

Blocking requests that look similar to real users is much harder.

An HTTP request can be syntactically correct and still be malicious in context.

Consider a sudden increase in searches.

Is it:

• a successful marketing campaign?
• a crawler?
• a newly released integration?
• an aggressive bot?
• a DDoS attack?

This is why application-layer DDoS detection often depends on behavior, not simply individual IP addresses.

Useful signals can include:

• request-rate changes
• repeated access to particular endpoints
• unusual user-agent patterns
• session behavior
• geographic distribution
• request parameters
• client reputation
• deviation from normal traffic baselines

There is rarely one magic threshold that identifies every DDoS attack.

What might developers see in production?

One reason DDoS incidents can initially be confusing is that they can resemble ordinary reliability problems.

Unexpected request or traffic spikes

Traffic increases quickly without a corresponding campaign, event, release, or other business explanation.

Rising latency

Requests that normally complete quickly begin taking significantly longer.

5xx errors and timeouts

Backend resources become constrained and legitimate requests fail.

Connection exhaustion

Load balancers, proxies, firewalls, or application infrastructure begin approaching connection limits.

One endpoint suddenly becomes very expensive

Login, search, product, checkout, or API routes may receive disproportionate traffic.

Highly distributed traffic

Similar behavior appears across many IP addresses, networks, or geographic locations.

Resource pressure

CPU, memory, bandwidth, connection tables, or database connection pools remain unusually high.

The important point is that none of these signals should be evaluated in isolation.

A useful baseline of normal traffic makes abnormal behavior much easier to recognize.

DoS vs. DDoS: what's the practical difference?

Both denial-of-service and distributed denial-of-service attacks are intended to affect availability.

The biggest difference is distribution.

Characteristic	DoS	DDoS
Traffic sources	Usually one or relatively few	Many distributed sources
Scale	Generally more limited	Can become extremely large
Blocking sources	Often more straightforward	Much more difficult
Resilience	Easier to interrupt at source	Distributed infrastructure makes this harder
Mitigation	Usually simpler	Often requires distributed filtering

With a DDoS campaign, blocking one attacking IP address may accomplish almost nothing.

Another thousand—or hundred thousand—sources can continue sending traffic.

What a 1.01 Tbps attack looked like in the real world

The scale stops being abstract when you look at an actual incident.

In a customer case documented by CDNetworks, a major software download platform was targeted by a ransom DDoS campaign.

During the campaign, the largest observed attack reached 1.01 Tbps and primarily combined SYN flood and ACK flood traffic.

The broader campaign lasted for more than a month.

There are several useful engineering lessons in that incident:

1. DDoS campaigns can be multi-vector.
   You may not be defending against one fixed attack pattern.

2. Attack intensity can change.
   A campaign can move between lower-volume and extremely high-volume periods.

3. Origin infrastructure should not be your only line of defense.
   Very large attacks may need to be filtered before they consume the network path to the origin.

4. Availability means preserving legitimate traffic, not simply blocking traffic.
   Dropping everything would technically stop the attack—but it would also accomplish the attacker's goal.

So how does DDoS mitigation work?

There isn't a single universal mitigation rule.

The response depends heavily on the attack layer.

At the network edge

Large volumetric attacks may need distributed capacity and upstream traffic scrubbing so malicious traffic is removed before reaching origin infrastructure.

At the protocol layer

Mitigation may involve connection validation, packet filtering, rate controls, and other mechanisms designed to prevent protocol-resource exhaustion.

At the application layer

Defenses can include:

• behavioral analysis
• rate controls
• WAF policies
• bot management
• endpoint-specific rules
• client reputation signals
• adaptive thresholds

The objective is not simply:

Block more traffic.

It is:

Identify and remove malicious traffic while allowing legitimate users to continue reaching the application.

That distinction matters.

A practical DDoS-readiness checklist for engineering teams

Before the incident happens, ask:

• Do we know what normal traffic looks like?
• Do we monitor bandwidth, packets, connections, and application requests separately?
• Which application endpoints are computationally expensive?
• Which endpoints can trigger large numbers of database operations?
• Are origin IP addresses exposed unnecessarily?
• Do we understand our load balancer and connection limits?
• What happens when a dependency becomes saturated?
• Who makes the decision to activate mitigation?
• Can high-volume malicious traffic be filtered before reaching the origin?
• Have engineering, networking, security, and incident-response teams agreed on an escalation process?

DDoS resilience is partly a security problem.

It is also an architecture, observability, networking, and incident-response problem.

Quick FAQ

Does DDoS mean the attacker has breached the application?

Not necessarily.

DDoS primarily targets availability rather than confidentiality. A service can be overwhelmed without the attacker gaining access to protected data.

However, security teams should still investigate other activity occurring during the incident. A disruptive attack can coexist with other malicious behavior.

How long can a DDoS attack last?

There is no standard duration.

An attack might last minutes or hours, or repeatedly return over a much longer campaign.

Can autoscaling solve DDoS?

Autoscaling can help applications absorb some legitimate demand and certain resource pressures, but it should not be treated as complete DDoS protection.

If an attacker can simply force you to provision more infrastructure—or saturate capacity upstream of that infrastructure—the fundamental problem remains.

Can small applications be targeted?

Yes.

Any public application, website, API, network service, or online platform can potentially be targeted.

Final thought

The most useful mental model for developers is not simply:

“DDoS means lots of traffic.”

Instead ask:

What resource is being exhausted, where is that resource located, and can malicious traffic be separated from legitimate traffic before it reaches that bottleneck?

Those three questions explain a surprising amount about both DDoS attacks and DDoS defense.