capacity planning

Everyone knows ulimit -n. The interview question is which process inherits which value, why limits.conf did nothing for your service, and how you size the ceiling honestly.

The answer that lands is about one epoll loop per core, not config snippets. Master versus worker duties, the arithmetic of worker_connections, and the limits people forget to raise.

Quotas are invisible until launch day. Treating them as tracked inventory with utilization alerts beats discovering them in a postmortem.

Distinguish executor capacity, placement and provisioning failures, then size an agent pool from measured resource use and cleanup behaviour.

Where linear models break: compounding growth, step functions, peak days and saturation cliffs. Forecast per constrained resource, backtest, subtract lead time to get the real order-by date.

Slow leaks hide inside restart cycles and percentage thresholds. Plot weeks of absolute memory against deploys, prove it with profiler deltas, and alert on predicted time-to-limit instead.

The Google-style NALSD round in miniature. The boxes are easy; what is being scored is whether the numbers fall out of Little's law before you draw them.

Queue time and build time are separate problems with separate fixes, and most teams spend a quarter optimising the one that is not hurting. Size the fleet from arrival rate, then attack the build with caching and graph awareness.

Four purchase instruments, one fleet, and a finance team asking why you did not commit to everything at maximum discount. The scoring rubric rewards the arithmetic of being wrong, not the discount table.

The tool emits recommendations; the programme is everything around it. Interviewers use this question to see whether you can turn a dashboard into landed changes without breaking production or trust.

Tokens are the unit and input and output are priced differently. Get the arithmetic on the table in the first minute, because the number usually decides the design before any other consideration does.

GPU capacity is not elastic the way CPU is. On-demand means whatever is left after the reservations, and in a tight region that is nothing, so the availability problem and the cost problem are the same problem.

Requests-per-second is not the load unit, cold starts are minutes not seconds, and scale-in can kill paying users mid-sentence. Everything you know about HPA needs re-deriving here.

The utilisation number everyone quotes means at least one kernel was resident, not that the hardware was doing useful work. A GPU at 95 percent can be doing five percent of what it is capable of.

Per-token pricing looks expensive until you compute what an idle GPU costs at 3am. Break-even depends on workload volume and duty cycle, measured throughput, and the engineering cost on both sides.