Round-robin (default) in Nginx - Time & Space Complexity
We want to understand how the work done by nginx grows when it uses the round-robin method to send requests to servers.
Specifically, how does the number of servers affect the time it takes to pick the next server?
Analyze the time complexity of the following nginx round-robin load balancing snippet.
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
server {
location / {
proxy_pass http://backend;
}
}
This configuration sends each incoming request to the next server in the list, cycling through them one by one.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Selecting the next server in the list for each request.
- How many times: Once per incoming request, cycling through all servers in order.
As the number of servers increases, nginx moves to the next server in the list for each request.
| Input Size (n servers) | Approx. Operations per request |
|---|---|
| 3 | 1 (just pick next server) |
| 10 | 1 (still just pick next server) |
| 100 | 1 (still just pick next server) |
Pattern observation: The work to select the next server stays the same no matter how many servers there are.
Time Complexity: O(1)
This means nginx picks the next server in constant time, regardless of how many servers are configured.
[X] Wrong: "Selecting the next server takes longer as the number of servers grows because nginx checks all servers each time."
[OK] Correct: nginx keeps track of the last used server and directly picks the next one without checking all servers, so the time stays constant.
Understanding how nginx handles load balancing efficiently shows you can think about how systems scale and keep performance steady as they grow.
"What if nginx used a weighted round-robin method instead? How would the time complexity change?"
Practice
Solution
Step 1: Understand round-robin behavior in nginx
Round-robin means distributing requests evenly by cycling through servers one by one.Step 2: Match behavior to options
Only It sends each new request to the next server in the list, cycling through them. describes cycling through servers for each new request.Final Answer:
It sends each new request to the next server in the list, cycling through them. -> Option DQuick Check:
Round-robin = cycling requests evenly [OK]
- Thinking round-robin sends all requests to one server
- Confusing round-robin with random or load-based methods
- Assuming round-robin skips servers
Solution
Step 1: Recall nginx upstream syntax
The default round-robin method requires only listing servers inside an upstream block without extra keywords.Step 2: Check each option for correctness
upstream backend { server server1.example.com; server server2.example.com; } correctly lists servers simply. Options B, C, and D use invalid or unsupported directives.Final Answer:
upstream backend { server server1.example.com; server server2.example.com; } -> Option BQuick Check:
Default round-robin needs only server list [OK]
- Adding unsupported directives like round_robin or balance
- Using incorrect keywords inside upstream block
- Forgetting semicolons after server lines
upstream backend {
server server1.example.com;
server server2.example.com;
server server3.example.com;
}What server will handle the 5th incoming request?
Solution
Step 1: Understand round-robin cycling through servers
Requests are sent in order: 1->server1, 2->server2, 3->server3, then cycle repeats.Step 2: Calculate 5th request server
Requests 4 and 5 cycle back: 4->server1, 5->server2.Final Answer:
server2.example.com -> Option AQuick Check:
5 mod 3 = 2, so server2 handles 5th request [OK]
- Assuming 5th request goes to server3
- Thinking load affects round-robin by default
- Starting count from zero instead of one
upstream backend {
server server1.example.com;
server server2.example.com;
server server3.example.com down;
}But requests are still sent to server3.example.com. What is the likely problem?
Solution
Step 1: Check correct usage of 'down' parameter
The 'down' flag must be placed immediately after the server address without extra spaces or errors.Step 2: Identify common syntax mistakes
If 'down' is misspelled or misplaced, nginx ignores it and still sends requests to that server.Step 3: Understand reload vs restart
Nginx requires a reload (nginx -s reload) to apply config changes like 'down'; a restart may not apply changes immediately.Final Answer:
The 'down' parameter requires a reload, not just restart. -> Option CQuick Check:
Reload nginx to apply 'down' flag changes [OK]
- Misspelling 'down' as 'dwon' or 'dnw'
- Placing 'down' on a separate line
- Not reloading nginx after config change
Solution
Step 1: Understand how to skip a server temporarily
Marking a server as 'down' tells nginx to skip it without removing it from config.Step 2: Evaluate other options
Removing the server line is permanent. 'weight=0' is invalid syntax. 'max_fails=0' disables failure detection but not requests.Final Answer:
Mark the server as 'down' in the upstream block to skip it. -> Option AQuick Check:
'down' flag skips server temporarily [OK]
- Removing server line instead of marking down
- Using invalid 'weight=0' syntax
- Confusing max_fails with disabling server
Ready to prove it?
Pass the test and this pattern moves unknown
