50 Từ Tiếng Anh Mọi Backend Developer Gặp Hàng Ngày
Nếu bạn làm backend development, có khoảng 50 từ xuất hiện trong ít nhất một tài liệu, cuộc thảo luận hoặc code review mỗi ngày. Bạn đã thấy tất cả chúng. Bạn có thể biết hầu hết. Nhưng có một nhóm con — 10 hoặc 15 từ mà bạn biết lờ mờ — nơi sự hiểu biết mơ hồ tạo ra vấn đề thực sự trong đọc documentation, thảo luận architecture, và tính đúng đắn của code.
Đây là danh sách đó.
Mỗi entry bao gồm định nghĩa chính xác, domain nó xuất hiện nhiều nhất, và ví dụ sử dụng để neo ý nghĩa trong ngữ cảnh.
Network & Distributed Systems
1. throughput
Lượng công việc mà một hệ thống có thể xử lý trong một đơn vị thời gian. Trong API: request/giây. Trong data pipeline: record/phút.
"Pipeline của chúng ta có throughput 50.000 events/phút ở quy mô hiện tại."
2. latency
Thời gian trôi qua giữa khi gửi request và nhận response. Thường đo bằng millisecond (ms) hoặc microsecond (µs).
"P99 latency tăng vọt lên 800ms sau khi deploy — cần tìm nguyên nhân."
3. idempotent / idempotency
Một operation là idempotent nếu gọi nó nhiều lần cho ra kết quả giống như gọi nó một lần. Critical trong payment API và distributed system khi retry phổ biến.
"Làm endpoint charge trở nên idempotent bằng cách chấp nhận header Idempotency-Key."
4. circuit breaker
Design pattern phát hiện lỗi ở downstream service và tạm dừng gửi request đến chúng, ngăn failure cascade. Đặt tên theo thiết bị an toàn điện.
"Circuit breaker trên inventory service đã trip sau 5 lần timeout liên tiếp."
5. backoff (exponential backoff)
Chiến lược retry trong đó delay giữa các retry tăng theo cấp số nhân (ví dụ: 1s, 2s, 4s, 8s) để giảm tải lên service đang gặp khó khăn.
"Triển khai exponential backoff với jitter để tránh thundering herd khi retry storm."
6. rate limiting
Kiểm soát số request mà client có thể thực hiện trong một khoảng thời gian nhất định. Thường trả về HTTP 429 khi vượt quá.
"Chúng ta áp dụng rate limiting 1.000 request/phút mỗi API key."
7. throttling
Tương tự rate limiting nhưng thường có nghĩa là làm chậm request thay vì từ chối chúng. Service degradates gracefully thay vì trả về lỗi.
"Dưới tải nặng, search service throttle response thay vì drop request."
8. graceful degradation
Khả năng của hệ thống duy trì chức năng một phần khi một số component bị lỗi, thay vì fail hoàn toàn.
"Ngay cả khi recommendation service bị down, product page vẫn nên load với graceful degradation."
9. failover
Tự động chuyển sang hệ thống hoặc component backup khi primary bị lỗi.
"Database failover sang read replica hoàn thành trong chưa đầy 10 giây."
10. load balancing
Phân phối request đến giữa nhiều server để ngăn bất kỳ server nào bị quá tải.
"Chúng ta thêm instance thứ ba sau load balancer để xử lý traffic peak."
Data & Consistency
11. reconciliation
Quá trình đảm bảo hai bộ data record đồng thuận. Phổ biến trong hệ thống tài chính: reconcile transaction log với bank record.
"Job reconciliation hàng ngày tìm ra chênh lệch $3 giữa sổ cái và báo cáo payout của Stripe."
12. eventual consistency
Model dùng trong distributed database nơi data update được propagate bất đồng bộ. Tất cả node cuối cùng sẽ có cùng data, nhưng không ngay lập tức.
"Vì chúng ta dùng eventual consistency, một số user có thể thấy số lượng product cũ trong tối đa 30 giây."
13. atomicity
Tính chất của transaction nơi tất cả operation thành công cùng nhau hoặc tất cả thất bại cùng nhau — không có trạng thái một phần.
"Bọc debit và credit trong một transaction duy nhất để đảm bảo atomicity."
14. schema
Cấu trúc được định nghĩa của data model: tên field, kiểu dữ liệu, relationship, và validation rule.
"Chúng ta đang migrate schema cũ để thêm field 'timezone' bắt buộc vào bảng users."
15. serialization / deserialization
Chuyển đổi cấu trúc dữ liệu thành định dạng để lưu trữ hoặc truyền dẫn (serialization) và ngược lại (deserialization).
"Service deserialize event payload từ Kafka trước khi xử lý nó."
16. normalization
Tổ chức database để giảm data redundancy. Schema "normalized" lưu mỗi thông tin một lần; "denormalized" duplicate data để tăng hiệu suất query.
"Normalization cao giảm storage và update anomaly nhưng tăng độ phức tạp JOIN."
17. sharding
Horizontal partitioning database bằng cách chia data qua nhiều database instance (shard) dựa trên key.
"Chúng ta shard bảng orders theo user_id để phân phối tải đọc/ghi."
18. replication
Sao chép data từ một database node (primary) sang một hoặc nhiều node khác (replica) để đảm bảo reliability và read scaling.
"Chúng ta có 3 read replica để offload report query khỏi primary."
API Design
19. endpoint
URL cụ thể kết hợp với HTTP method để định nghĩa một API operation.
"POST /orders tạo order mới; GET /orders/:id lấy về nó."
20. webhook
Server-to-server callback: hệ thống của bạn gửi HTTP POST đến URL được cấu hình khi một event cụ thể xảy ra.
"Chúng ta gửi webhook đến hệ thống partner khi trạng thái order thay đổi thành 'đã giao hàng'."
21. pagination
Chia result set lớn thành các trang rời rạc được trả về tuần tự. Pattern phổ biến: offset-based, cursor-based.
"Triển khai cursor-based pagination để tránh vấn đề hiệu suất của giá trị OFFSET lớn."
22. deprecation
Đánh dấu tính năng hoặc endpoint API là lỗi thời. Nó vẫn hoạt động nhưng sẽ bị xóa trong phiên bản tương lai.
"Endpoint v1/users bị deprecate và sẽ bị xóa sau tháng 3 năm 2027. Vui lòng migrate sang v2/users."
23. breaking change
Bất kỳ thay đổi API nào yêu cầu caller hiện tại phải cập nhật code của họ. Xóa field, đổi tên parameter, hoặc thay đổi status code đều là breaking change.
"Làm field 'email' bắt buộc là breaking change — các integration hiện tại có thể không gửi nó."
24. backward compatibility
Cập nhật API mà client hiện tại có thể consume mà không cần sửa đổi. Field optional mới thường backward-compatible; xóa field thì không.
"Thêm field optional mới duy trì backward compatibility với client v1."
25. idempotency key
Định danh duy nhất do client tạo ra, được bao gồm trong request header để server có thể phát hiện và xử lý an toàn các request duplicate.
"Tạo UUID làm Idempotency-Key trước khi charge — nếu request fail, retry với cùng key đó."
26. polling
Gọi API endpoint lặp đi lặp lại trong khoảng thời gian cố định để kiểm tra xem trạng thái của resource có thay đổi không.
"Đừng poll endpoint trạng thái job mỗi giây — dùng webhook hoặc triển khai exponential backoff polling."
27. payload
Phần data body của HTTP request hoặc response, không bao gồm header.
"Payload của event checkout completed chứa order ID, tổng cộng và line item."
Auth & Security
28. authentication
Xác minh danh tính — chứng minh bạn là ai. Thường qua credential (username/password), token (JWT) hoặc certificate.
"API yêu cầu authentication qua Bearer token trong header Authorization."
29. authorization
Xác minh quyền hạn — chứng minh bạn được phép làm gì. Xảy ra sau authentication.
"User đã authenticated nhưng thiếu authorization để xóa order — họ chỉ có role 'viewer'."
30. JWT (JSON Web Token)
Định dạng token nhỏ gọn, URL-safe tự chứa các claim được mã hóa (user ID, role, expiry). Có thể xác minh mà không cần tra cứu database bằng signing key.
"JWT chứa claim 'roles' — validate phía server trước khi cấp quyền admin."
31. OAuth 2.0
Framework authorization cho phép ứng dụng truy cập user resource thay mặt user, mà không expose password.
"Dùng OAuth 2.0 để cho phép user cấp quyền đọc Google Calendar cho app của chúng ta."
32. scope
Trong OAuth: quyền cụ thể mà access token cấp phép. Token nên có scope tối thiểu cần thiết.
"Chỉ request scope 'calendar.readonly' — đừng xin quyền ghi nếu bạn không cần."
33. refresh token
Credential tồn tại lâu được dùng để lấy access token ngắn hạn mới mà không cần user authenticate lại.
"Lưu refresh token an toàn — nó nhạy cảm như password."
34. HMAC
Hash-Based Message Authentication Code. Chữ ký mật mã được tính từ thông điệp và secret key, dùng để xác minh tính toàn vẹn và xác thực của data.
"Validate Stripe webhook signature dùng HMAC-SHA256 trước khi xử lý event."
Performance
35. caching
Lưu kết quả của operation tốn kém để các request tương lai có thể được phục vụ nhanh hơn. Các cấp độ: in-memory (Redis), CDN, browser.
"Cache data profile user trong Redis với TTL 5 phút để giảm tải database."
36. TTL (Time-To-Live)
Thời gian một item được cache vẫn hợp lệ trước khi được coi là stale và phải được refresh.
"Đặt TTL 60 giây cho số lượng tồn kho — staleness chấp nhận được cho các trang non-checkout."
37. cache invalidation
Quá trình xóa hoặc cập nhật các cache entry cũ khi data bên dưới thay đổi.
"Cập nhật cart cache mỗi khi thêm/xóa item để duy trì nhất quán — đừng chỉ dựa vào TTL."
38. N+1 query
Anti-pattern hiệu suất: fetch danh sách N record, sau đó thực hiện thêm một query cho mỗi record để fetch data liên quan, tổng cộng N+1 database query.
"Endpoint orders có N+1 query — dùng eager loading để JOIN line item trong một query duy nhất."
39. index (database)
Cấu trúc dữ liệu cải thiện tốc độ tra cứu query bằng chi phí lưu trữ thêm và thời gian ghi.
"Thêm composite index trên (user_id, created_at DESC) để tăng tốc độ lookup orders."
40. connection pooling
Duy trì một tập hợp database connection có thể tái sử dụng để tránh overhead tạo connection mới mỗi request.
"Đặt kích thước connection pool để match expected peak concurrent query của bạn."
Reliability & Observability
41. SLA (Service Level Agreement)
Cam kết hợp đồng về mức dịch vụ cụ thể, thường được biểu đạt dưới dạng uptime (ví dụ: 99,9% = ~8,7 giờ downtime/năm).
"SLA của chúng ta đảm bảo 99,9% uptime — mỗi outage ngoài kế hoạch làm tốn ngân sách đó."
42. SLO (Service Level Objective)
Mục tiêu nội bộ cho độ tin cậy của service. SLO là mục tiêu; SLA là hợp đồng.
"P99 latency SLO của chúng ta là 300ms — chúng ta alert khi trung bình 7 ngày vượt quá."
43. observability
Mức độ mà trạng thái nội bộ của hệ thống có thể được suy ra từ các output bên ngoài: metric, log và trace.
"Thêm distributed tracing để cải thiện observability qua ranh giới microservice."
44. distributed tracing
Theo dõi một request duy nhất khi nó di chuyển qua nhiều microservice, gắn trace ID để correlate log giữa các service.
"Dùng header X-Trace-ID để propagate trace qua tất cả các service call downstream."
45. idempotent consumer
Message queue consumer được thiết kế để xử lý an toàn cùng một message nhiều lần mà không có side effect. Thiết yếu trong hệ thống at-least-once delivery.
"Làm payment consumer idempotent — duplicate message từ Kafka sẽ xuất hiện đôi khi."
Code & Process
46. refactoring
Tái cấu trúc code hiện có để cải thiện chất lượng nội bộ — readability, maintainability, performance — mà không thay đổi hành vi bên ngoài.
"Chúng ta refactor payment module để extract retry logic thành shared utility."
47. regression
Bug được giới thiệu bởi một thay đổi làm hỏng chức năng đã hoạt động trước đó.
"Deploy gây ra regression trong checkout flow — đang revert về build trước."
48. dependency
Library, service hoặc component mà code của bạn dựa vào. Quản lý dependency là mối quan tâm cốt lõi của bất kỳ build system nào.
"Pin phiên bản dependency trong lockfile của bạn để tránh breakage bất ngờ từ thay đổi upstream."
49. race condition
Bug xảy ra khi tính đúng đắn của hệ thống phụ thuộc vào timing của các concurrent operation.
"Không có database lock, hai checkout request đồng thời có thể giảm tồn kho xuống dưới 0 — đó là race condition."
50. dead letter queue (DLQ)
Queue nơi các message xử lý thất bại được gửi sau khi vượt quá giới hạn retry, để kiểm tra thủ công và replay.
"Route các payment event thất bại đến DLQ và alert on-call để điều tra trước khi replay."
Học 50 Từ Này Mà Không Cần Ngồi Học
Mỗi từ trong danh sách này là từ bạn sẽ thấy lại trong hai tuần làm việc bình thường tiếp theo. Cách hiệu quả nhất để chuyển từ "biết lờ mờ" sang "biết chắc" không phải là một khóa học từ vựng — mà là spaced repetition, được giao vào những lúc não bạn available.
Wordrop cho phép bạn import danh sách từ tùy chỉnh và tự động giao phiên ôn tập trong menu bar Mac của bạn — trong khi CI build đang chạy, giữa các cuộc họp, và trong giờ nghỉ trưa. 50 từ trên là điểm khởi đầu sẵn sàng.