Backup servers in Nginx - Time & Space Complexity
We want to understand how the time to handle requests changes when using backup servers in nginx.
Specifically, how does nginx's processing time grow as the number of servers increases?
Analyze the time complexity of the following nginx configuration snippet.
upstream backend {
server primary.example.com;
server backup1.example.com backup;
server backup2.example.com backup;
}
server {
location / {
proxy_pass http://backend;
}
}
This config defines one primary server and two backup servers for handling requests.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: nginx tries the primary server first for each request.
- How many times: If the primary fails, nginx tries backup servers one by one until one responds or all fail.
As the number of backup servers grows, nginx may try more servers before success or failure.
| Input Size (n) | Approx. Operations |
|---|---|
| 1 backup server | 1 to 2 tries per request |
| 5 backup servers | 1 to 6 tries per request |
| 10 backup servers | 1 to 11 tries per request |
Pattern observation: The number of tries grows linearly with the number of backup servers.
Time Complexity: O(n)
This means the time to find a working server grows in a straight line as you add more backup servers.
[X] Wrong: "Adding backup servers does not affect request handling time because only one server is used."
[OK] Correct: If the primary server fails, nginx tries backups one by one, so more backups can increase the time before a response.
Understanding how backup servers affect request handling time helps you explain real-world load balancing and failover strategies clearly and confidently.
"What if nginx tried all backup servers in parallel instead of one by one? How would the time complexity change?"
Practice
backup in an upstream block in nginx?Solution
Step 1: Understand the role of backup servers
Backup servers are fallback servers used only when main servers fail.Step 2: Analyze the
Marking a server asbackupkeyword effectbackupmeans it will receive traffic only if main servers are down.Final Answer:
To use it only if all main servers are unavailable -> Option AQuick Check:
Backup servers = fallback only [OK]
- Thinking backup servers share load equally
- Assuming backup servers are always active
- Confusing backup with disabled servers
upstream block?Solution
Step 1: Recall nginx upstream server syntax
The correct syntax isserver [IP] [parameters];with parameters likebackupafter IP.Step 2: Identify correct placement of
Thebackupbackupkeyword comes after the IP address in the server line.Final Answer:
server 192.168.1.10 backup; -> Option CQuick Check:
Backup keyword after IP = correct syntax [OK]
- Placing 'backup' before IP address
- Using 'backup server' instead of 'server ... backup;'
- Omitting semicolon at line end
upstream backend {
server 10.0.0.1;
server 10.0.0.2 backup;
}Which server will nginx send requests to if
10.0.0.1 is up?Solution
Step 1: Understand upstream with backup server
Main server 10.0.0.1 handles requests first; backup 10.0.0.2 is fallback.Step 2: Check server availability
Since 10.0.0.1 is up, nginx sends all requests there, ignoring backup.Final Answer:
10.0.0.1 only -> Option AQuick Check:
Backup used only if main down [OK]
- Assuming backup server shares load
- Thinking backup server is always active
- Believing nginx sends requests to both simultaneously
upstream backend {
server 192.168.0.1 backup;
server 192.168.0.2;
}What is wrong with this configuration?
Solution
Step 1: Validate syntax and parameters
All server lines have correct syntax, valid IPs, proper semicolons, and correctbackupusage.Step 2: Check server order
Position of backup servers does not matter; nginx ignores them unless all main servers fail.Final Answer:
Nothing is wrong with this configuration -> Option DQuick Check:
Backup position irrelevant [OK]
- Thinking backup servers must be listed after main servers
- Believing server order causes failures
- Assuming 192.168.x.x IPs are invalid
server1 and server2 normally, but use backup1 and backup2 only if both main servers fail. Which configuration correctly sets this up?Solution
Step 1: Identify main and backup servers
Main servers are server1 and server2; backup servers are backup1 and backup2.Step 2: Apply correct syntax and order
Main servers listed first withoutbackup, backups listed after withbackupkeyword.Step 3: Verify options
upstream backend { server server1; server server2; server backup1 backup; server backup2 backup; } correctly lists main servers first, backups withbackupkeyword after.Final Answer:
upstream backend { server server1; server server2; server backup1 backup; server backup2 backup; } -> Option BQuick Check:
Main servers first, backups last with 'backup' keyword [OK]
- Placing backup servers before main servers
- Missing 'backup' keyword on backup servers
- Marking main servers as backup by mistake
Ready to prove it?
Pass the test and this pattern moves unknown
