E ExamMaster

GATE Computer Science & IT · System Design

Load vs capacity

Arrivals versus what a CampusClip host can finish — excess, utilisation, and QPS × payload.

CampusClip now has a name for work: a student opening a short link. This topic separates how many opens arrive from how many one host can finish, then multiplies a finish rate by a reply size we set for the app. No industry-typical QPS appears — only the classroom numbers we state.

  • GATE Computer Science & IT
  • Medium level
  • 5 concepts

1Load is arrivals

Load is how much work shows up. For CampusClip's read path, load is students opening short links: arrivals per second. It is not "how busy the host feels" and it is not the size of the college. Eight hundred students on campus is a population; load is how many of them open a link in the same second.

We will treat a midterm-notice minute as a classroom given: at 9:00, students open the same short link at 10 arrivals per second. That 10/s is a number we chose for this lesson so later arithmetic has something to multiply. It is not a claim about a production shortener.

Figure. This lesson's given read-path load: 10 short-link opens start each second. Population (800) is not the bar.

How to name the load

  1. Pick the pathHere: opens of a short link (the read path).
  2. Count arrivalsHow many such opens start in one second.
  3. Keep the unitArrivals per second — not "800 students" and not "the server is hot".
CampusClip's college has 800 students. In one second, 10 of them open the midterm short link. The load on the read path is
  1. 10 arrivals per second
  2. 800 students
  3. 800 minus 10 idle students

Load is arrivals in the interval, not the population. 800 is how many people exist; 10/s is how many requests started.

2Capacity is what the host can finish

Capacity is how much work one CampusClip host can finish in a second — completed redirects, not arrivals. We give this host a classroom capacity of 20 redirects per second. That is a property of this host in this lesson, not a typical industry box.

Load and capacity use the same unit so they can be compared: arrivals per second versus finishes per second. A host that finishes 20/s can keep up with 10 arrivals/s. The 800-student population still does not appear in that comparison.

Figure. Same units: 10 arrivals/s against a host that can finish 20/s. The host is not full.

How to name the capacity

  1. Name the workA finished redirect (lookup + 302 reply).
  2. Count finishesHow many such replies this host completes in one second.
  3. Compare like unitsArrivals/s versus finishes/s — never students versus finishes.
CampusClip host H is given as finishing 20 redirects per second. That number is
  1. H's capacity — completed work per second
  2. The campus population
  3. The arrival rate at 9:00

Capacity is finishes per second on that host. Population is 800; the 9:00 arrival rate was 10/s.

3When load exceeds capacity

If arrivals stay above what the host can finish, the extra work does not vanish. It waits (a queue grows), it is dropped, or the student's open times out. Those are three different failures; "the server is slow" is not a fourth kind — slowness is often the queue being visible as latency.

Keep the classroom numbers. Host capacity stays 20 redirects/s. Now suppose a second notice goes out and arrivals become 40/s. Excess is 40 - 20 = 20 redirects/s that this host cannot finish. Each second the wait pile grows by 20 unless something else absorbs them — another host, a drop policy, or a later topic's queue in front of a worker.

Figure. Arrivals 40/s over a 20/s host. The terracotta bar is twice the sage bar — that gap is the excess, 20/s.

What the excess can do

  1. WaitUnfinished opens sit in a queue; students see higher latency.
  2. DropCampusClip refuses some opens so the host stays at 20/s finished.
  3. TimeoutThe student gives up; the work may still be in flight.

Excess arrivals on one host

CampusClip host capacity is 20 redirects/s. Arrivals jump to 40/s. How many redirects per second cannot finish on this host?

  • Capacity20 / s
  • Arrivals40 / s
  • Excess = 40 - 2020 / s

Pro tip. Excess is arrivals minus capacity in the same unit. It is not a percentage until you choose to write it as one.

Arrivals 40/s, capacity 20/s, and CampusClip has no second host and no drop policy. The 20/s excess
  1. Waits — a queue grows by about 20 unfinished opens each second
  2. Disappears because the host "tries harder"
  3. Equals 800 minus 40 students

Unfinished work accumulates unless you drop it or add capacity. Trying harder is not a third finish rate. Population is the wrong unit.

4Utilisation and headroom

Utilisation is the fraction of capacity that arrivals are already using: \rho = \lambda / \mu, where \lambda is arrivals per second and \mu is finishes per second. For the 9:00 minute, \lambda = 10 and \mu = 20, so \rho = 10/20 = 0.5. Half the host's finish rate is spoken for.

Headroom is the unused fraction, 1 - \rho. At \rho = 0.5 you have half a host left for a burst. Running at \rho = 1 means any extra arrival waits. That is why a design that "fits on average" can still fail at 9:00: the average hid a minute at \rho > 1.

Figure. The 20/s host at 10 arrivals/s: ten finishes/s used, ten left. The two bars are equal — ρ = 0.5.

How to read ρ

  1. Divide\rho = \lambda / \mu in the same unit.
  2. Under one\rho < 1 means finishes can keep up; headroom is 1 - \rho.
  3. At or over one\rho \ge 1 means every extra arrival waits or is dropped.

Utilisation at 9:00

Arrivals 10/s, host capacity 20/s. What is utilisation, and how much headroom is left?

  • \rho = \lambda / \mu = 10 / 200.5
  • Headroom = 1 - 0.50.5
  • Unused finish rate = 0.5 \times 2010 / s

Pro tip. ρ is a fraction of capacity, not a second number of students. Unused finish rate is headroom × μ.

Arrivals 18/s on a 20/s host. Utilisation is
  1. 0.9
  2. 18
  3. 2

\rho = 18/20 = 0.9. 18 is the arrival rate; 2 is the unused finish rate, not ρ.

5Bytes on the wire = QPS × payload

A finish rate is not a byte rate until you multiply by the size of one reply. CampusClip's redirect reply in this course is 250 bytes (status line plus a Location header — a size we set for the app). At the host's 20 redirects/s, outbound bytes are 20 \times 250 = 5000 bytes/s.

That product is the only scale number this topic will write. It does not become "megabits on a real NIC" unless you convert units; we stop at 5000 bytes/s so the multiplication stays visible. If arrivals are only 10/s, the same reply size gives 10 \times 250 = 2500 bytes/s — load, not capacity, times payload.

Figure. Outbound bytes are QPS times payload. CampusClip finishes 20 redirects/s and each 302 is 250 bytes, so 20 × 250 = 5000 bytes/s. The figure stops there; it is not converted to megabits.

How the product is built

  1. Name QPSRedirects finished per second (or arrivals, if you want offered load).
  2. Name payloadBytes in one reply — here 250, given for CampusClip.
  3. MultiplyBytes/s = QPS \times bytes per reply.

Outbound bytes at capacity

CampusClip finishes 20 redirects/s. Each redirect reply is 250 bytes. What is the outbound byte rate?

  • QPS20 / s
  • Payload250 bytes
  • Bytes/s = 20 \times 2505000 bytes/s

Pro tip. Change either factor and the product changes. 10 arrivals/s × 250 bytes is 2500 bytes/s — that is offered load, not capacity.

If CampusClip's reply were 250 bytes and arrivals were 10/s, offered outbound load is
  1. 2500 bytes/s
  2. 5000 bytes/s
  3. 250 bytes/s

10 \times 250 = 2500. 5000 is the 20/s capacity product. 250 bytes/s forgets the ten arrivals.

Notes

  • Load is arrivals per second on a named path, not the size of the user population.
  • Capacity is finished work per second on a named host, in the same unit as load.
  • When load exceeds capacity the excess waits, is dropped, or times out — it does not vanish.
  • Utilisation ρ = λ/μ; headroom is 1 − ρ. At ρ = 1 every extra arrival waits.
  • Byte rate = QPS × bytes per reply, using sizes you actually state for the app.

Formulas

  • Excess rate = \lambda - \mu when \lambda > \mu (same unit).
  • Utilisation \rho = \lambda / \mu.
  • Headroom = 1 - \rho; unused finish rate = (1 - \rho)\,\mu.
  • Bytes/s = QPS \times payload bytes.

Exam traps & shortcuts

  • If the units differ (students vs redirects/s), you are not yet comparing load to capacity.
  • ρ = 1 is full, not "healthy". Healthy is unused finish rate you can point at.

Reference tables

Every row uses the CampusClip read path and the numbers we stated.

Load vs capacity sheet
QuantityCampusClip givenMeaning
Load λ10 / s at 9:00 (40 / s in the burst)Arrivals — opens that start
Capacity μ20 / s on host HFinishes — redirects completed
Payload250 bytesOne 302 reply, as we set it
ρ at 9:0010 / 20 = 0.5Half the host is spoken for

Recap

Arrivals, finishes, and one product.

Load
Arrivals/s on a path — not the 800-student population.
Capacity
Finishes/s on a host. Compare only in the same unit.
Excess
λ − μ waits, drops, or times out. It does not vanish.
ρ
λ/μ. Headroom is 1 − ρ. ρ = 1 means the next arrival waits.
Bytes
QPS × payload. 20 × 250 = 5000 bytes/s at this host's capacity.

Practise Load vs capacity

Reading is free and needs no account. Practice, mocks and progress live in the app.

  • A 3-question practice set that ends the chapter
  • 5 quick checks with worked explanations
  • Timed mocks scored with the real marking scheme
  • Readiness tracked per topic, kept on your device
Continue with Google — freeNo card, no trial. Works offline once installed.