5 exercises — essential IT terms every developer should know: latency, technical debt, idempotency, bottleneck, and feature flags. Each question appears in a realistic code review or Slack context.
These terms appear across all IT roles
Latency — delay between request and response; measured in ms; p50/p95/p99 percentiles
Technical debt — accumulated cost of shortcuts; paid down through refactoring
Idempotent — same result regardless of how many times you call it; critical for APIs and retries
Bottleneck — the component limiting overall system throughput
Feature flag — deploy code without releasing; enables gradual rollout, A/B testing, kill switches
0 / 5 completed
1 / 5
A senior engineer says: "This function has high latency — users are waiting 3 seconds for data that should arrive in under 200ms." What does latency mean?
Latency = the delay or time lag between a request and its response. Measured in milliseconds (ms). Usually described from the user's perspective: "page load latency", "API latency", "database query latency."
Latency vs. throughput — the most important pair in performance: • Latency = how long one request takes (time dimension). Lower is better. "P99 latency is 450ms" = the slowest 1% of requests take 450ms or more. • Throughput = how many requests the system handles per unit time (volume dimension). Higher is better. "The service handles 5,000 requests per second."
Percentile notation — standard in production monitoring: • p50 (median): 50% of requests are faster than this • p95: 95% of requests are faster than this — the "typical slow case" • p99: 99% of requests are faster — the "worst normal case" • p99.9 (three nines): the extreme tail
Common latency vocabulary: • round-trip time (RTT) — time for a packet to travel to destination and back • time to first byte (TTFB) — how long until the browser gets the first byte of a response • cold start latency — extra delay when spinning up a serverless function from idle state
2 / 5
A product manager writes: "We need to address the technical debt in the auth module before adding new features — it's making every change take three times longer." What is technical debt?
Technical debt = the accumulated cost of shortcuts, poor design, and quick fixes that make the codebase harder to work with over time. Like financial debt, it accumulates interest: the longer you leave it, the more expensive it becomes to fix.
The term was coined by Ward Cunningham in 1992. Originally it described intentional short-term shortcuts; today it's used for any accumulated code quality problems.
Types of technical debt: • Deliberate debt — knowingly shipping a quick solution to meet a deadline: "We'll do this properly in Q3" • Accidental debt — poor decisions made without realising the future cost • Bit rot — code that degrades over time as dependencies and requirements change around it
Related vocabulary: • refactoring — restructuring existing code without changing its behaviour (paying off technical debt) • legacy code — old code, often without tests, that is fear-inducing to change • code smell — a pattern in code that suggests a deeper problem: long methods, magic numbers, deep nesting • hotfix — an emergency fix applied directly to production outside the normal release cycle (often creates debt)
3 / 5
In a code review, a reviewer comments: "This operation is not idempotent — calling it twice will charge the customer twice." What does idempotent mean?
Idempotent = applying the same operation multiple times produces the same result as applying it once. The outcome doesn't change with repetition.
Why it matters in APIs and distributed systems: Networks fail. Clients retry. If your operation is not idempotent, a retry can cause duplicate actions — charging a card twice, creating duplicate records, or sending an email twice.
HTTP methods and idempotency: • GET — idempotent ✅ (reading doesn't change state) • PUT — idempotent ✅ (setting a resource to a value — same result if repeated) • DELETE — idempotent ✅ (deleting something already deleted still results in it being absent) • POST — NOT idempotent ❌ (creating a resource twice creates two resources) • PATCH — depends on implementation
Making operations idempotent — common pattern: Use an idempotency key — a unique ID the client generates and sends with the request. The server checks: "have I processed this key before?" and returns the cached result instead of executing again. Stripe, PayPal, and most payment APIs use this pattern.
4 / 5
A developer explains a performance problem: "The database is a bottleneck — we can scale the API servers horizontally, but all requests still funnel through the same single database instance." What is a bottleneck?
Bottleneck = the component, step, or resource that limits the overall capacity of a system. Like a bottle whose neck restricts how fast liquid can flow, a system bottleneck restricts the total throughput regardless of how much you optimise other parts.
Bottleneck in practice: If your API can handle 10,000 req/sec but your database can only handle 1,000 queries/sec, the database is the bottleneck. Doubling API server capacity won't help — the database is still the limit.
Identifying bottlenecks — Amdahl's Law: The speedup from optimising one part of a system is limited by the fraction of time that part takes. If the bottleneck is 50% of the total work, fixing it perfectly only doubles performance at best.
Common IT bottlenecks and solutions: • Database bottleneck → read replicas, query optimisation, connection pooling, caching • Network bottleneck → CDN, compression, reducing round trips • CPU bottleneck → horizontal scaling, profiling hot functions • I/O bottleneck → faster disks (SSD/NVMe), async I/O, buffering • Lock contention bottleneck → reduce critical sections, use lock-free algorithms
5 / 5
A tech lead writes in a PR description: "This feature is behind a feature flag — we can deploy it to production now and enable it for specific users or regions without a new release." Which statement best describes a feature flag?
Feature flag (also: feature toggle, feature switch) = a configuration variable that lets you turn a feature on or off without deploying new code. The feature is in production but inactive until the flag is enabled.
Why feature flags are fundamental in modern development: • Decouple deployment from release — ship code when it's ready; release the feature when the business is ready • Gradual rollout — enable for 1% of users, monitor, then 10%, 50%, 100% • A/B testing — show version A to half your users and version B to the other half; measure which performs better • Kill switch — instantly disable a buggy feature in production without rolling back the entire deployment • Canary release — enable for internal users first ("canaries") before broader release
Feature flag services: LaunchDarkly, Unleash, Flagsmith, AWS CloudWatch evidently
Technical debt risk: Flags that are never cleaned up become "zombie flags" — permanent conditionals in the codebase. Best practice: set an expiry date for every flag and remove it once the rollout is complete.