IT Vocabulary in Context

Regression tests verify that previously working features still work after a change (a bug fix, a refactor, a new feature). The name comes from "software regression" — when a fix accidentally re-introduces an old bug or breaks something else.

The other options in context:
• Smoke tests — fast, shallow checks that the application starts and the most critical paths work. Run first, before deeper tests. "Does the app boot? Does login work?"
• Unit tests — test a single function or class in isolation. Fast and focused, but don't test component interaction.
• Integration tests — test how multiple components work together (e.g., API + database). Slower and broader than unit tests.

How they fit in a CI pipeline:
commit → unit tests (fast) → integration tests (slower) → regression tests → deploy

Common usage:
"The regression suite caught a broken session timeout that wasn't covered by the unit tests."
"We don't have enough regression coverage — every hotfix risks breaking the login flow."

Feature flag (also called a feature toggle or feature switch) — a configuration variable that enables or disables a feature at runtime without redeploying code. The code ships, but the feature is "off" for most users until explicitly enabled.

Common use cases:
• Canary releases — enable the feature for 1–5% of users to monitor for errors before full rollout
• Internal testing — enable for employees only first ("dogfooding")
• A/B testing — show feature A to 50% of users and feature B to the other 50%; measure which performs better
• Kill switch — if a released feature causes a spike in errors, disable it instantly without a rollback deployment
• Gradual rollout — enable for 10%, then 25%, then 50%, then 100%

Feature flag tools: LaunchDarkly, Unleash, Flagsmith, Optimizely, Azure Feature Flags, AWS AppConfig

The other options:
• Rate limiter — restricts how many requests a user/IP can make per second/minute
• Circuit breaker — stops calling a failing downstream service to prevent cascading failures
• Load balancer — distributes incoming traffic across multiple server instances

Idempotent (adjective) — producing the same result whether you perform the operation once or many times. From mathematics: f(f(x)) = f(x).

In APIs and distributed systems, idempotency is critical because networks fail and clients retry requests. A retry in a non-idempotent endpoint can have unintended consequences (duplicate charges, double emails, duplicate database records).

HTTP method idempotency:
• GET — idempotent and safe (no side effects)
• PUT — idempotent (setting a resource to a value twice gives the same result)
• DELETE — idempotent (deleting what's already deleted returns the same state)
• POST — NOT idempotent by default (each call creates a new resource)
• PATCH — may or may not be idempotent, depending on implementation

Solution for non-idempotent operations: use an idempotency key — a unique ID the client sends with the request. The server stores the key and, if it sees the same key again, returns the original response instead of processing again. Stripe, Braintree, and most payment APIs require this.

Example header: Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000

Refactor (verb) — to restructure existing code without changing its external behaviour. The goal is to improve readability, maintainability, and structure — not to add features or fix bugs. Named after "factoring" in mathematics: rearranging an expression into a cleaner form.

Key point: refactoring preserves behaviour. If you change what the code does, it's not a refactor — it's a modification.

Common refactoring operations:
• Extract function — pull repeated code into a named function
• Rename variable — give a variable a clearer name (x → userSessionToken)
• Replace conditional with polymorphism — replace nested if-else chains with object-oriented design patterns
• Remove duplication — DRY (Don't Repeat Yourself)
• Split large function — a 300-line function becomes five 60-line functions

Refactoring and technical debt: technical debt accumulates when developers take shortcuts ("we'll clean it up later"). Refactoring pays down that debt. The quote in the exercise is a classic description of technical debt — "tangled mess of global variables."

The other options:
• Deprecate — mark something as outdated and scheduled for removal, but keep it temporarily so existing users can migrate
• Document — write documentation; doesn't restructure the code
• Compile — translate source code to machine code; a build-time operation

Scalable (adjective) — capable of handling increasing load (more users, more data, more requests) without degrading in performance or availability. Scalability is one of the most important non-functional requirements in software engineering.

Two types of scaling:
• Vertical scaling (scaling up) — add more resources to a single server: more CPU, more RAM, faster storage. Simple, but has a physical upper limit and creates a single point of failure.
• Horizontal scaling (scaling out) — add more servers and distribute the load between them. More complex (requires load balancing, stateless design, distributed data), but theoretically unlimited. Preferred for modern cloud architectures.

Why "not scalable" causes outages:
If servers are stateful (store user sessions locally), you can't just add more servers — sessions break. If the database is a single node, it becomes the bottleneck. If the application can't run in multiple parallel instances, horizontal scaling is impossible.

Related terms:
• Load balancer — distributes traffic across multiple instances
• Autoscaling — cloud infrastructure that automatically adds/removes servers based on traffic
• Stateless design — each request is self-contained; sessions stored in Redis/JWT, not in server memory — required for horizontal scaling
• Elasticity — ability to scale both up (more load) and back down (less load) dynamically

In software development, 'coupled' refers to the degree of interdependence between different modules or components. A highly coupled function is tightly connected to specific external systems like a database – changes in one directly impact the other. This makes testing and modification more difficult; options A and B accurately describe this relationship.

'Rate limiting' is a crucial defense mechanism used to prevent abuse and overload of an API. It restricts the number of requests that a client can make within a given timeframe, safeguarding the backend service from being overwhelmed – option B is the correct definition.

A 'pull strategy' in WebSockets means that the server actively requests updates from connected clients rather than waiting for them to send data. This approach is more efficient for handling a high volume of users and incoming messages – option B accurately reflects this behavior.

'Latency' is a fundamental concept in networking and distributed systems – it measures the delay between sending a request and receiving its response. Option B correctly defines latency as the time taken for a process to complete; options A, C, and D represent different metrics.

'Cold starts' are a characteristic challenge in serverless environments. When a serverless function hasn't been invoked recently, the underlying infrastructure needs to be initialized before it can execute – this initial delay is what's known as a 'cold start'. Options B, C, and D describe different aspects of serverless services.