50 Technical English Terms Every Backend Developer Half-Knows (And Gets Wrong in Production)

The Words You "Know" That Are Causing Bugs

There's a specific category of technical English word that's more dangerous than a word you don't know at all.

If you don't know a word, you look it up. Problem solved.

If you half-know a word — you have a rough sense of what it means, enough to use it in conversation without sounding confused — you don't look it up. You keep using it with the wrong precision. And that imprecision eventually lands somewhere it can't afford to.

A developer who half-knows idempotent might make a payment endpoint that double-charges under retry. A developer who confuses throttling with rate limiting implements the wrong failure behavior. A developer who conflates authentication with authorization ships an access control bug.

This isn't a language problem. It's a precision problem. And it's fixable.

This glossary covers the 50 technical English terms that appear in at least one code review, architecture doc, or standup per week for most backend developers. Each entry has: a precise definition, the exact context it appears in, and a real usage example from code reviews or documentation.

Read through the ones you half-know. The ones where you feel slightly uncertain whether your mental model is exactly right — those are the ones to focus on.

How These Words Appear in Real Code Reviews

Before the glossary, here's what precise technical vocabulary looks like in actual code review comments — the context where imprecision causes the most friction:

// ❌ Vague code review comment (forces back-and-forth)
"This might cause issues with duplicate requests."

// ✅ Precise comment using technical vocabulary
"This endpoint isn't idempotent — if the client retries after a timeout,
we'll create a duplicate order. Add an Idempotency-Key header and store
processed keys for 24h to make retries safe."

// ❌ Vague architecture discussion
"We should make the system handle failures better."

// ✅ Precise discussion
"We need graceful degradation here — when the recommendation service
is unavailable, the product page should still load with the cached
top-10 list instead of returning a 503."

// ❌ Standup: "I'm looking into the slow API issue."
// ✅ Standup: "P99 latency on the /checkout endpoint spiked to 1.2s
// after yesterday's deploy. Investigating whether it's an N+1 query
// or a downstream service adding to the critical path."

The second version in each case communicates the problem precisely, implies the right solution direction, and doesn't require follow-up questions. That's what technical vocabulary actually does in practice — it compresses meaning and reduces coordination overhead.

Network & Distributed Systems

1. throughput
The volume of work a system processes per unit of time. In APIs: requests per second (rps). In data pipelines: records per minute or events per second.
> Code review: "Our current throughput is 8,000 rps on a single instance — adding a second should take us to 15,000 accounting for coordination overhead."

2. latency
The time elapsed between sending a request and receiving a response. Measured in milliseconds (ms) or microseconds (µs). Usually reported as P50, P95, P99 (median, 95th percentile, 99th percentile) to capture tail behavior.
> Code review: "P99 latency spiked to 800ms after the deploy — median is fine but something's causing outlier slowness. Check for lock contention."

3. idempotent / idempotency
An operation is idempotent if calling it multiple times with the same input produces the same result as calling it once. Critical in payment APIs and any system where network retries are possible.
> Code review: "The charge endpoint must be idempotent. If the client gets a timeout and retries, we cannot create two charges. Implement an Idempotency-Key header and store processed keys."

4. circuit breaker
A resilience pattern that monitors calls to a downstream service and, after a threshold of failures, "opens" — stopping further calls to that service for a recovery period. Prevents failure cascades.
> Code review: "Wrap the inventory service call in a circuit breaker. If inventory is down, we should fail open (allow checkout with a low-stock warning) rather than blocking the entire checkout flow."

5. backoff / exponential backoff
A retry strategy where the delay between retries increases exponentially (1s → 2s → 4s → 8s) to reduce pressure on a struggling downstream service. "With jitter" adds randomness to prevent synchronized retry storms.
> Code review: "Add exponential backoff with jitter on the Stripe API call — without jitter, all clients retry simultaneously after a timeout and create a thundering herd."

6. rate limiting
Controlling the number of requests a client can make in a given time window. When exceeded, returns HTTP 429 (Too Many Requests). Protects the server from overload.
> Code review: "Apply rate limiting at 100 requests/minute per API key at the gateway level, before requests reach the service."

7. throttling
Similar to rate limiting, but instead of rejecting excess requests, the service slows them down — adds delay, queues them, or degrades response quality. The system handles more but more slowly.
> Code review: "Under load, the search service should throttle rather than reject — a slow result is better than a 429 for most use cases."

8. graceful degradation
A system design principle: when a component fails, the system maintains partial functionality rather than failing completely. The opposite of a hard dependency.
> Code review: "The recommendation service call shouldn't be in the critical path. If it fails, render the page without personalized recommendations — graceful degradation over hard failure."

9. failover
Automatically switching traffic from a failed primary system to a backup (standby or replica) system.
> Code review: "Test the failover path — manually bring down the primary and verify traffic shifts to the replica within 10 seconds."

10. load balancing
Distributing incoming requests across multiple servers to prevent any single instance from becoming a bottleneck. Common strategies: round-robin, least connections, consistent hashing.
> Code review: "After the third instance comes up, the load balancer will include it automatically — verify the health check endpoint returns 200 before marking it ready."

Data & Consistency

11. reconciliation
The process of comparing two data sets to find and resolve discrepancies. Common in financial systems: comparing transaction logs against external records (bank, payment processor).
> Code review: "The nightly reconciliation job should log every discrepancy it finds between our ledger and Stripe's payout report, not just the total mismatch."

12. eventual consistency
A consistency model in distributed systems where data updates propagate asynchronously across nodes. All nodes will have the same data eventually, but reads immediately after a write may return stale data.
> Code review: "User sees stale follower count because of eventual consistency in the read replica — acceptable for social counts, but flag this in the product spec."

13. atomicity
The property that a group of operations either all succeed or all fail together — no partial states. One of the ACID properties of database transactions.
> Code review: "Wrap the debit and credit operations in a single transaction. Atomicity guarantees that if the credit fails, the debit rolls back — we never create money or destroy it."

14. schema
The defined structure of a data model: field names, data types, constraints, and relationships. Also refers to the GraphQL or database structure definition itself.
> Code review: "This is a schema migration — adding a NOT NULL column requires a default value or a backfill before deploying, or it will break existing rows."

15. serialization / deserialization
Serialization: converting an in-memory data structure to a storable or transmittable format (JSON, protobuf, Avro). Deserialization: the reverse. Also called "marshaling/unmarshaling" in some ecosystems.
> Code review: "The service deserializes the Kafka event payload before processing. If the schema evolves, old messages in the topic may fail deserialization — add a fallback."

16. normalization / denormalization
Normalization: organizing a database to reduce data redundancy — each piece of information stored once. Denormalization: deliberately duplicating data to optimize for query performance at the cost of consistency overhead.
> Code review: "This design is denormalized — we're storing username in the posts table to avoid joining users. Document that it requires sync when username changes."

17. sharding
Horizontally partitioning a database by splitting data across multiple independent database instances (shards) based on a partition key (often user_id, tenant_id).
> Code review: "We shard by user_id — cross-user queries will span multiple shards and can't be done with a single SQL JOIN. Plan for that in the reporting layer."

18. replication
Copying data from a primary database node to one or more replica nodes, continuously. Provides read scaling (route reads to replicas) and high availability (failover if primary dies).
> Code review: "Route report queries to the read replica — they can tolerate 1–5 second replication lag and shouldn't compete with write traffic on primary."

API Design

19. endpoint
A specific URL + HTTP method combination that defines an API operation. GET /orders and POST /orders are two different endpoints on the same resource.
> Code review: "Add a PATCH /orders/:id endpoint for partial updates — PUT should only be used for full resource replacement."

20. webhook
A server-to-server event notification: your service sends an HTTP POST to a pre-configured URL owned by the receiving service when a specific event occurs. Push-based alternative to polling.
> Code review: "Implement retry logic for webhook delivery — if the receiver returns 5xx, retry with exponential backoff up to 24 hours before moving to the DLQ."

21. pagination
Dividing large result sets into discrete pages. Two main patterns: offset-based (?page=3&per_page=20) is simple but degrades at large offsets; cursor-based (?after=cursor_abc) is consistent and performant at scale.
> Code review: "Switch to cursor-based pagination — offset pagination with OFFSET 10000 causes a full table scan on every request."

22. deprecation
Marking an API feature, endpoint, or parameter as obsolete — still functional, but scheduled for removal in a future version. Requires advance notice and migration path for API consumers.
> Code review: "Add a Deprecation and Sunset header to the v1 endpoint with the removal date — consumers need machine-readable deprecation signals, not just docs."

23. breaking change
Any API change that requires existing callers to update their client code. Removing a field, renaming a parameter, changing a response status code, or tightening validation are breaking changes.
> Code review: "Making 'email' required is a breaking change — existing v1 clients that don't send it will start getting 400s. This needs a major version bump and deprecation period."

24. backward compatibility
An API update that existing clients can consume without any code changes. Adding optional fields, adding new endpoints, and relaxing validation are backward-compatible. Removing or renaming anything usually isn't.
> Code review: "Adding 'metadata' as an optional field is backward-compatible — existing clients that don't send or read it are unaffected."

25. polling
Repeatedly querying an API endpoint at fixed intervals to check whether a resource's state has changed. Simple to implement but inefficient. Webhooks or server-sent events are the preferred alternative for async operations.
> Code review: "Polling the job status endpoint every 500ms generates 7,200 requests/hour per client. Use a webhook callback or long-polling instead."

26. payload
The data body of a request or response — the actual content, excluding headers. Usually JSON in REST APIs; binary formats (protobuf, MessagePack) for higher throughput systems.
> Code review: "Log the request payload on 4xx responses (redacting PII fields) — we need visibility into malformed inputs without logging everything."

Auth & Security

27. authentication
Verifying identity — who you are. Typically via credentials (username + password), tokens (JWT, API key), or certificates. Authentication precedes authorization.
> Code review: "The middleware does authentication (validates the JWT signature and expiry) before the route handler runs authorization checks."

28. authorization
Verifying permissions — what you're allowed to do. Happens after authentication establishes identity. A user can be authenticated but not authorized for a specific action.
> Code review: "User is authenticated but the authorization check is missing — any logged-in user can currently call DELETE /admin/users. Add role validation."

29. JWT (JSON Web Token)
A self-contained, signed token that encodes claims (user ID, roles, expiry time) in a compact URL-safe format. The server verifies the signature without a database lookup, which makes JWTs stateless but unrevocable until expiry.
> Code review: "Don't store sensitive data in the JWT payload — it's base64-encoded, not encrypted. Any party with the token can decode the payload without the signing key."

30. OAuth 2.0
An authorization framework that allows a third-party application to access user resources on behalf of the user, without the user sharing their credentials with the third-party app.
> Code review: "Use the authorization code flow, not the implicit flow — implicit flow exposes the access token in the URL fragment, which ends up in browser history and server logs."

31. scope
In OAuth 2.0: the set of permissions an access token grants. Follow the principle of least privilege — request only the scopes your application actually needs.
> Code review: "We're requesting 'drive.file' scope (full Drive access) when we only need 'drive.appdata'. Request the minimum scope — users see the permission dialog."

32. refresh token
A long-lived credential that allows a client to obtain a new short-lived access token without requiring the user to authenticate again. Treat with the same security as a password.
> Code review: "Store the refresh token in HttpOnly cookies, not localStorage — JavaScript can't access HttpOnly cookies, so XSS attacks can't steal it."

33. HMAC
Hash-Based Message Authentication Code — a cryptographic signature computed from a message body and a secret key. Used to verify that a webhook or API request came from the expected sender and wasn't tampered with.
> Code review: "Validate the Stripe webhook signature using HMAC-SHA256 before processing the event payload. Reject events with invalid signatures — don't just log them."

Performance

34. caching
Storing the result of an expensive computation or query so subsequent requests for the same result can be served faster. Tradeoff: speed vs. data freshness. Levels: in-process memory, Redis/Memcached, CDN edge.
> Code review: "Cache the user's permission set in Redis with a 5-minute TTL — it changes rarely and querying it per request adds 30ms to every API call."

35. TTL (Time-To-Live)
How long a cached entry remains valid before being considered stale. Too short: cache misses are frequent, no performance benefit. Too long: stale data serves longer than acceptable.
> Code review: "60-second TTL on product prices is too long — prices change in near-real-time during flash sales. Reduce to 5 seconds or use cache invalidation on price change events."

36. cache invalidation
Explicitly removing or updating a cache entry when the underlying data changes, rather than waiting for the TTL to expire. One of the hardest problems in distributed systems.
> Code review: "Invalidate the user profile cache on any profile update, not just on TTL expiry — otherwise the old avatar shows for up to 5 minutes after a profile photo change."

37. N+1 query
A performance anti-pattern: fetching N records, then making one additional database query per record to retrieve related data — totaling N+1 queries instead of 1 or 2. A common source of unexpected latency spikes.
> Code review: "This endpoint has an N+1 query — for 100 orders, we make 100 separate queries to fetch the user for each order. Use eager loading or a JOIN to fetch everything in one query."

38. index (database)
A data structure that speeds up read queries on one or more columns at the cost of additional storage and slower writes. Without an index on a filter column, the database scans the entire table.
> Code review: "Add a composite index on (user_id, created_at DESC) — the query filters by user_id and orders by created_at, and both need index support to avoid a full table scan."

39. connection pooling
Maintaining a pool of reusable database connections rather than opening and closing a new connection per request. Without pooling, connection overhead dominates latency at any meaningful scale.
> Code review: "Set the connection pool max size to match your worker count, not to the database's connection limit — overloading the pool just shifts the bottleneck."

Reliability & Observability

40. SLA (Service Level Agreement)
A contractual commitment to a specific service level, typically expressed as uptime percentage. 99.9% SLA = ~8.7 hours of allowable downtime per year. 99.99% = ~52 minutes.
> Code review: "Every unplanned outage over 5 minutes burns SLA budget — instrument this critical path and alert before the SLA threshold is breached."

41. SLO (Service Level Objective)
An internal reliability target — the goal your team sets for itself. SLOs are internal; SLAs are external contracts. A common setup: SLO is stricter than SLA to give a safety buffer.
> Code review: "Our P99 latency SLO is 300ms — this query regularly takes 450ms. It needs optimization before it starts breaching SLO and burning error budget."

42. error budget
The allowed amount of unreliability within a measurement period, derived from the SLO. If your SLO is 99.9% availability over 30 days, your error budget is ~43 minutes of downtime. When the budget runs out, feature work stops to focus on reliability.
> Code review: "We've burned 60% of this month's error budget in the last 3 days. No new features until the reliability issues are resolved."

43. observability
The degree to which a system's internal state can be inferred from its external outputs: metrics, logs, and distributed traces. A system is observable if you can diagnose any problem without adding new instrumentation.
> Code review: "The service isn't observable enough — we have no way to determine which downstream call is contributing latency without adding traces. Add distributed tracing before the next release."

44. distributed tracing
Tracking a single request as it travels through multiple services by attaching a unique trace ID to every log line, metric, and outgoing call in the request path. Correlates logs across service boundaries.
> Code review: "Propagate the X-Trace-ID header to all downstream service calls and include it in every log line — without it, correlating a single user's request across 5 services is manual detective work."

45. idempotent consumer
A message consumer (Kafka, SQS, RabbitMQ) that processes the same message multiple times without producing duplicate side effects. Required in at-least-once delivery systems, where duplicate message delivery is guaranteed to eventually occur.
> Code review: "The payment consumer must be idempotent — Kafka guarantees at-least-once delivery. Store the message ID in Redis before processing; skip on duplicates."

Code & Process

46. refactoring
Restructuring existing code to improve internal quality — readability, maintainability, testability — without changing external behavior. A refactor that changes behavior is a bug fix or feature, not a refactor.
> Code review: "This is a good refactor — the behavior is identical but the payment module is now testable in isolation. Confirm the existing integration tests still pass."

47. regression
A bug introduced by a change that breaks previously working functionality. Regressions are discovered through regression testing — running existing tests after a change to verify nothing broke.
> Code review: "The deploy caused a regression in the checkout flow — users with zero-balance gift cards now get a 500 instead of a validation error. Rolling back."

48. dependency
A library, service, or component your code relies on. Direct dependencies are declared explicitly; transitive dependencies are pulled in by your direct dependencies. Dependency management is a core concern of every build system.
> Code review: "Pin the dependency version in the lockfile — an unpinned dependency will silently pull in the latest patch version on each build, and patches can introduce regressions."

49. race condition
A bug where the correctness of a program depends on the relative timing of concurrent operations — and incorrect behavior occurs when the timing is "wrong." Common in systems with shared mutable state.
> Code review: "Two concurrent checkout requests can both read inventory as 1, both decrement, and both succeed — leaving inventory at -1. Add a database-level lock or use optimistic locking to prevent the race condition."

50. dead letter queue (DLQ)
A queue where messages are routed after exceeding the maximum number of processing retries. The DLQ holds messages for manual inspection and selective replay after the underlying issue is resolved.
> Code review: "After 5 failed processing attempts, route the message to the DLQ with the failure reason and original message ID. Alert on-call when the DLQ has more than 10 unprocessed messages."

The 10 Most Commonly Confused Pairs

These are the terms backend developers most often conflate. If any pair feels fuzzy, that's the one to focus on:

How to Move From Half-Knowing to Fully Knowing These Terms

Knowing the definitions above is step one. Being able to use these terms precisely — in a standup, in a code review comment, in a technical interview — requires a different kind of practice: active recall under realistic conditions.

The most effective approach, supported by research on vocabulary retention:

• Don't re-read the glossary — that's passive review and builds only familiarity
• Test yourself — cover the definition, produce it from the term alone
• Space the reviews — review a term when you're about to forget it, not immediately after reading it
• Use the term in context — next time you encounter the concept in code, use the precise term in your comment or message

For developers who want to turn this glossary into durable long-term memory, the specific reason this is hard without a system is explained in why the Ebbinghaus Forgetting Curve affects technical vocabulary the same way it affects any other learning →.

And if you're building toward a remote role, the specific vocabulary priorities for that path are covered in the developer salary and English gap breakdown →.

Import this glossary into Wordrop and start reviewing with spaced repetition →

Frequently Asked Questions

How many technical English terms does a backend developer actually need to know?

For daily backend work — understanding documentation, participating in code reviews, and following architecture discussions — a core set of 50–100 specialized terms covers the majority of what you'll encounter. This doesn't include general English vocabulary, just domain-specific terms. The good news: this is a bounded set. You're not learning a language from scratch; you're learning a professional vocabulary layer on top of your existing English.

What's the difference between a technical English vocabulary problem and a general English fluency problem?

Technical vocabulary is domain-specific — a word like idempotent doesn't appear in everyday English conversation, so it doesn't get reinforced through normal immersion. This is why developers who can read English news fluently still struggle with technical documentation: the vocabulary sets are almost entirely different. Technical vocabulary requires targeted acquisition; general fluency helps but doesn't automatically deliver it.

Which of these 50 terms causes the most production bugs when misunderstood?

Idempotency-related bugs (duplicate payments, duplicate resource creation) are the most severe and most common result of imprecise technical vocabulary. Developers who understand "idempotent" as "has no side effects" (which is statelessness, not idempotency) build retry mechanisms that create duplicate records. Authentication vs. authorization confusion leads to access control bugs. N+1 query issues frequently persist because developers describe symptoms ("slow API") without identifying the pattern.

How long does it take to genuinely learn all 50 terms?

Initial acquisition — reading and understanding each definition — takes 1–2 hours. Moving from "I read this" to "I can recall and use it precisely under pressure" takes 3–6 weeks of spaced repetition review, typically 5–10 minutes per day. After that, the terms stay accessible with minimal maintenance as long as you continue encountering them in your work.

Is it better to learn these terms from context (reading documentation) or from explicit study?

Both contribute, but differently. Contextual reading builds intuition for usage. Explicit study builds precision of definition. The problem with context-only learning: you'll encounter a term like "eventual consistency" used correctly in 10 different sentences and still not be able to define it precisely, because the context assumes you already know the definition. Start with explicit study for precision, then contextual reading reinforces and extends it.

How do I know which terms I half-know versus which I actually know?

A simple test: for each term, close the glossary and write a one-sentence definition plus a realistic code review comment using the term. If you hesitate, rewrite it twice, or feel uncertain whether your usage is correct — that's a half-known term. This takes about 20 minutes for the full 50-term list and reliably surfaces the gaps that matter.