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 / 10 completed
1 / 10
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 / 10
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 / 10
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 / 10
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 / 10
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.
6 / 10
Sarah (a junior developer) sends a Slack message to the team: 'I'm seeing a lot of 500 errors in our API. The response times are also really slow – sometimes over a minute!'. What does 'response time' refer to, in this context?
Response time is a crucial metric in API performance. It specifically measures the duration – typically in milliseconds or seconds – that it takes for a server to process a request and send back its response. A high response time indicates potential bottlenecks or slow processing on the server-side. Option A describes the *data* returned, not the timing of the response.
7 / 10
Mark (a senior developer) writes a comment in a code review: 'This function should be designed to handle multiple inputs gracefully. If it receives the same input twice, it shouldn't produce unexpected or incorrect results.' What concept is Mark highlighting?
Idempotency is key here. It describes an operation (like a function) that produces the same outcome regardless of how many times it's executed with the *same input*. This is critical for reliability in distributed systems. While data validation and error handling are important, they don't directly address the core concern of consistent results across multiple executions.
8 / 10
David (a DevOps engineer) is troubleshooting a deployed application. He observes: 'The load balancer is consistently saturated – all incoming requests are being directed to the backend servers.' What does 'saturated' mean in this context?
When a load balancer is 'saturated,' it means it's receiving more traffic than it can effectively process. This leads to bottlenecks and delays. The load balancer's primary role is to distribute requests; saturation indicates that distribution isn't happening optimally, and the backend servers are overwhelmed. Options 2-4 describe *causes* of saturation, not its definition.
9 / 10
Emily (a product manager) is documenting a new feature in a PR description: 'This release includes a toggle that allows us to enable or disable the functionality for specific user segments. We can roll out changes without releasing a full version.' What does she mean by 'toggle'?
Feature flags are used to decouple deployment from release. A toggle is simply the mechanism – often a boolean setting – that controls whether a new feature is visible and active for particular users or groups. This allows for controlled testing and gradual rollouts without impacting all users simultaneously. Options 2-4 describe *what* a toggle *is*, not its purpose.
10 / 10
John (a developer) is investigating performance issues with a microservice. He discovers that the service consistently spends a significant amount of time waiting for data from another service. What term best describes this situation?
Service coupling refers to a strong dependency where one service relies heavily on another's availability and performance. This creates a bottleneck because the dependent service's latency directly affects the primary service's operation. Options 2-4 describe solutions for improving performance, but don't explain what is causing the delay in this scenario.
What does the "General IT Terms — Match to Definition" vocabulary exercise cover?
This exercise tests real IT vocabulary related to general it terms — match to definition through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.