The 50 English Words Every Backend Developer Encounters Daily
If you work in backend development, there are roughly 50 words that appear in at least one document, discussion, or code review every single day. You've seen all of them. You probably know most of them. But there's a subset — the 10 or 15 that you half-know — where a fuzzy understanding creates real problems in documentation reading, architecture discussions, and code correctness.
This is that list.
Each entry includes a precise definition, the domain it appears in most, and a usage example to anchor the meaning in context.
Network & Distributed Systems
1. throughput
The volume of work a system can process per unit of time. In APIs: requests per second. In data pipelines: records per minute.
> "Our pipeline has a throughput of 50,000 events/minute at current scale."
2. latency
The time elapsed between sending a request and receiving a response. Usually measured in milliseconds (ms) or microseconds (µs).
> "P99 latency spiked to 800ms after the deploy — we need to find the culprit."
3. idempotent / idempotency
An operation is idempotent if calling it multiple times produces the same result as calling it once. Critical in payment APIs and distributed systems where retries are common.
> "Make the charge endpoint idempotent by accepting an Idempotency-Key header."
4. circuit breaker
A design pattern that detects failures in downstream services and temporarily stops sending requests to them, preventing failure cascades. Named after the electrical safety device.
> "The circuit breaker on the inventory service tripped after 5 consecutive timeouts."
5. backoff (exponential backoff)
A retry strategy where delay between retries increases exponentially (e.g., 1s, 2s, 4s, 8s) to reduce load on a struggling service.
> "Implement exponential backoff with jitter to prevent thundering herd on retry storms."
6. rate limiting
Controlling the number of requests a client can make in a given time window. Usually returns HTTP 429 when exceeded.
> "We apply rate limiting at 1,000 requests/minute per API key."
7. throttling
Similar to rate limiting but typically means slowing down requests rather than rejecting them. The service degrades gracefully instead of returning errors.
> "Under heavy load, the search service throttles responses rather than dropping requests."
8. graceful degradation
A system's ability to maintain partial functionality when some components fail, rather than failing completely.
> "Even when the recommendation service is down, the product page should still load with graceful degradation."
9. failover
Automatically switching to a backup system or component when the primary fails.
> "Database failover to the read replica completed in under 10 seconds."
10. load balancing
Distributing incoming requests across multiple servers to prevent any single server from becoming overloaded.
> "We added a third instance behind the load balancer to handle peak traffic."
Data & Consistency
11. reconciliation
The process of ensuring that two sets of data records agree. Common in financial systems: reconciling transaction logs against bank records.
> "The daily reconciliation job found a $3 discrepancy between our ledger and Stripe's payout report."
12. eventual consistency
A model used in distributed databases where data updates propagate asynchronously. All nodes will eventually have the same data, but not instantly.
> "Because we use eventual consistency, some users may see stale product counts for up to 30 seconds."
13. atomicity
The property of a transaction where all operations succeed together or all fail together — no partial states.
> "Wrap the debit and credit in a single transaction to guarantee atomicity."
14. schema
The defined structure of a data model: field names, data types, relationships, and validation rules.
> "We're migrating the old schema to add a required 'timezone' field to the users table."
15. serialization / deserialization
Converting data structures into a format for storage or transmission (serialization) and back (deserialization). Common formats: JSON, protobuf, MessagePack.
> "The service deserializes the event payload from Kafka before processing it."
16. normalization
Organizing a database to reduce data redundancy. A "normalized" schema stores each piece of information once; a "denormalized" schema duplicates data for query performance.
> "High normalization reduces storage and update anomalies but increases JOIN complexity."
17. sharding
Horizontally partitioning a database by splitting data across multiple database instances (shards) based on a key.
> "We shard the orders table by user_id to distribute read/write load."
18. replication
Copying data from one database node (primary) to one or more others (replicas) for reliability and read scaling.
> "We have 3 read replicas to offload report queries from the primary."
API Design
19. endpoint
A specific URL combined with an HTTP method that defines an API operation.
> "The /orders POST endpoint creates a new order; GET /orders/:id retrieves it."
20. webhook
A server-to-server callback: your system sends an HTTP POST to a configured URL when a specific event occurs.
> "We send a webhook to partner systems when order status changes to 'shipped'."
21. pagination
Dividing large result sets into discrete pages returned sequentially. Common patterns: offset-based, cursor-based.
> "Implement cursor-based pagination to avoid the performance issues of large OFFSET values."
22. deprecation
Marking an API feature or endpoint as obsolete. It continues to function but will be removed in a future version.
> "The v1/users endpoint is deprecated and will be removed after March 2027. Please migrate to v2/users."
23. breaking change
Any API change that requires existing callers to update their code. Removing a field, renaming a parameter, or changing a status code are all breaking changes.
> "Making the 'email' field required is a breaking change — existing integrations may not send it."
24. backward compatibility
An API update that existing clients can consume without modification. New optional fields are typically backward-compatible; removing fields is not.
> "Adding new optional fields maintains backward compatibility with v1 clients."
25. idempotency key
A unique client-generated identifier included in a request header so the server can detect and safely handle duplicate requests.
> "Generate a UUID as the Idempotency-Key before the charge — if the request fails, retry with the same key."
26. polling
Repeatedly calling an API endpoint at fixed intervals to check whether a resource's state has changed.
> "Don't poll the job status endpoint every second — use webhooks or implement exponential backoff polling."
27. payload
The data body of an HTTP request or response, not including headers.
> "The payload of the checkout completed event contains the order ID, total, and line items."
Auth & Security
28. authentication
Verifying identity — proving who you are. Usually via credentials (username/password), tokens (JWT), or certificates.
> "The API requires authentication via Bearer token in the Authorization header."
29. authorization
Verifying permissions — proving what you're allowed to do. Happens after authentication.
> "The user is authenticated, but lacks authorization to delete orders — they only have 'viewer' role."
30. JWT (JSON Web Token)
A compact, URL-safe token format that self-contains encoded claims (user ID, roles, expiry). Verifiable without a database lookup using the signing key.
> "The JWT contains a 'roles' claim — validate it server-side before granting admin access."
31. OAuth 2.0
An authorization framework that allows applications to access user resources on behalf of the user, without exposing passwords.
> "Use OAuth 2.0 to let users grant our app read access to their Google Calendar."
32. scope
In OAuth: the specific permissions an access token grants. Tokens should have the minimum scope required.
> "Request only the 'calendar.readonly' scope — don't ask for write access you don't need."
33. refresh token
A long-lived credential used to obtain a new short-lived access token without asking the user to authenticate again.
> "Store the refresh token securely — it's as sensitive as a password."
34. HMAC
Hash-Based Message Authentication Code. A cryptographic signature computed from a message and a secret key, used to verify data integrity and authenticity.
> "Validate the Stripe webhook signature using HMAC-SHA256 before processing the event."
Performance
35. caching
Storing the result of an expensive operation so future requests can be served faster. Levels: in-memory (Redis), CDN, browser.
> "Cache the user's profile data in Redis with a 5-minute TTL to reduce database load."
36. TTL (Time-To-Live)
How long a cached item remains valid before it's considered stale and must be refreshed.
> "Set a 60-second TTL on inventory quantities — acceptable staleness for non-checkout pages."
37. cache invalidation
The process of removing or updating stale cache entries when underlying data changes.
> "Update the cart cache on every item add/remove to keep it consistent — don't rely on TTL alone."
38. N+1 query
A performance anti-pattern: fetching a list of N records, then making one additional query per record to fetch related data, totaling N+1 database queries.
> "The orders endpoint had an N+1 query — use eager loading to join line items in a single query."
39. index (database)
A data structure that improves query lookup speed at the cost of additional storage and write time.
> "Add a composite index on (user_id, created_at DESC) to speed up the orders lookup."
40. connection pooling
Maintaining a set of reusable database connections to avoid the overhead of creating a new connection per request.
> "Set the connection pool size to match your expected peak concurrent queries."
Reliability & Observability
41. SLA (Service Level Agreement)
A contractual commitment to a specific service level, often expressed as uptime (e.g., 99.9% = ~8.7 hours of downtime/year).
> "Our SLA guarantees 99.9% uptime — every unplanned outage costs against that budget."
42. SLO (Service Level Objective)
An internal target for service reliability. SLOs are goals; SLAs are contracts.
> "Our P99 latency SLO is 300ms — we alert when the 7-day average exceeds it."
43. observability
The degree to which a system's internal state can be inferred from external outputs: metrics, logs, and traces.
> "Add distributed tracing to improve observability across the microservices boundary."
44. distributed tracing
Tracking a single request as it travels through multiple microservices, attaching a trace ID to correlate logs across services.
> "Use the X-Trace-ID header to propagate the trace through all downstream service calls."
45. idempotent consumer
A message queue consumer designed to safely process the same message multiple times without side effects. Essential in at-least-once delivery systems.
> "Make the payment consumer idempotent — duplicate messages from Kafka will arrive occasionally."
Code & Process
46. refactoring
Restructuring existing code to improve internal quality — readability, maintainability, performance — without changing external behavior.
> "We refactored the payment module to extract the retry logic into a shared utility."
47. regression
A bug introduced by a change that breaks previously working functionality.
> "The deploy caused a regression in the checkout flow — reverting to the previous build."
48. dependency
A library, service, or component that your code relies on. Managing dependencies is a core concern of any build system.
> "Pin dependency versions in your lockfile to prevent unexpected breakage from upstream changes."
49. race condition
A bug that occurs when the correctness of a system depends on the timing of concurrent operations.
> "Without a database lock, two concurrent checkout requests can decrement inventory past zero — that's a race condition."
50. dead letter queue (DLQ)
A queue where messages that fail processing are sent after exceeding retry limits, for manual inspection and replay.
> "Route failed payment events to the DLQ and alert on-call to investigate before replaying."
Learn These 50 Without Sitting Down to Study
Every word on this list is one you'll see again in the next two weeks of normal development work. The most efficient way to move from "half-know" to "fully know" isn't a vocabulary course — it's spaced repetition, delivered at the moments when your brain is available.
Wordrop lets you import a custom word list and delivers review sessions automatically in your Mac's menu bar — during CI builds, between meetings, and over lunch. The 50 words above are a ready-made starting point.