Prometheus Lab

Chào anh em, 3 khái niệm này khi mới tìm hiểu kiến trúc backend thường rất dễ nhầm lẫn, vì nhìn chung cả 3 đều đứng ở giữa làm cầu nối cho Client (front-end, mobile) và Server (backend). Nhưng bản chất, mục đích sinh ra và cách hoạt động của chúng lại khác nhau khá rõ. Bài viết này sẽ đi sâu từng thằng một.

---

1. Reverse Proxy (Bác bảo vệ gác cổng)

1.1. Khái niệm

Bình thường anh em dùng Proxy (hay VPN) để đổi IP khi lướt web đúng không? Cái đó gọi là Forward Proxy — nó đứng ra thay mặt cho phía Client (người dùng) để giao tiếp với Internet.
Còn Reverse Proxy thì ngược lại hoàn toàn - nó đứng ra thay mặt cho phía Server (hệ thống backend). Người dùng gửi bất kỳ request nào đều va phải thằng Reverse Proxy đầu tiên và không bao giờ biết được backend thật đang nằm ở đâu.

1.2. Cơ chế hoạt động chi tiết

Client gửi request tới domain api.myapp.com.
DNS phân giải domain trỏ vào IP của con Reverse Proxy (chứ không phải IP của backend server thật).
Reverse Proxy nhận request, phân tích header/URL, rồi quyết định forward request đó vào backend server nội bộ nào (ví dụ 192.168.1.10:3000).
Backend server xử lý xong, trả kết quả về cho Reverse Proxy.
Reverse Proxy nhận kết quả, có thể nén lại (gzip/brotli), thêm header bảo mật, rồi gửi ngược về cho Client.

Trong suốt quá trình này, Client không hề biết con backend server thật là ai, nằm ở IP nào.

1.3. Các chức năng kỹ thuật quan trọng

a) SSL/TLS Termination (Chấm dứt mã hóa)

Việc mã hóa/giải mã HTTPS rất tốn CPU. Nếu anh em có 10 backend server thì phải quản lý SSL certificate trên cả 10 con, rất phiền.
Giải pháp: Đặt SSL certificate duy nhất trên con Reverse Proxy. Lúc này giao tiếp từ Client ↔ Reverse Proxy là HTTPS (mã hóa), còn từ Reverse Proxy ↔ Backend nội bộ chỉ cần HTTP thuần (không mã hóa) vì cùng nằm trong private network.
Lưu ý: Cách này gọi là "SSL Termination". Nếu anh em cần mức bảo mật cao hơn (ví dụ ngành tài chính, y tế) thì dùng "SSL Passthrough" hoặc "SSL Re-encryption" — tức là vẫn mã hóa cả đoạn bên trong.

b) Caching (Lưu đệm)

Reverse Proxy lưu lại response của các request phổ biến (đặc biệt là file tĩnh: ảnh, CSS, JS, HTML, video).
Khi có người request giống hệt, nó trả kết quả từ cache luôn mà không cần gọi vào backend, giúp giảm tải rất đáng kể.
Ví dụ cấu hình Nginx:

location /static/ {
    proxy_cache my_cache;
    proxy_cache_valid 200 302 60m;   # Cache response 200/302 trong 60 phút
    proxy_cache_valid 404 1m;        # Cache response 404 chỉ 1 phút
    proxy_pass http://backend_server;
}

c) Security Headers & Web Application Firewall (WAF)

Reverse Proxy có thể thêm các HTTP header bảo mật vào response trước khi trả về cho Client:
- X-Frame-Options: DENY — chống clickjacking
- X-Content-Type-Options: nosniff — chống MIME sniffing
- Content-Security-Policy — kiểm soát nguồn tài nguyên được phép tải
- Strict-Transport-Security (HSTS) — ép buộc trình duyệt chỉ dùng HTTPS
Một số Reverse Proxy (hoặc kết hợp module) còn hoạt động như WAF, lọc bớt các request có dấu hiệu tấn công SQL injection, XSS...

d) Compression (Nén dữ liệu)

Tự động nén response bằng gzip hoặc brotli trước khi gửi về cho Client.
Giảm đáng kể kích thước dữ liệu truyền qua mạng (ảnh hưởng trực tiếp đến tốc độ tải trang và chi phí bandwidth).

e) URL Rewriting

Cho phép viết lại URL trước khi forward vào backend. Ví dụ anh em muốn đường dẫn /v2/users ở ngoài được map thành /api/users ở bên trong backend.

1.4. Công cụ phổ biến

Công cụĐặc điểmNginxPhổ biến nhất, nhẹ, nhanh, cấu hình bằng file text. Cộng đồng cực lớn.Apache HTTP Server (mod_proxy)Lâu đời, nhiều module mở rộng, nhưng tốn RAM hơn Nginx khi chịu tải cao.CaddyTự động xin và renew SSL certificate (Let's Encrypt). Cấu hình cực kỳ đơn giản.EnvoySinh ra cho thời đại Cloud-native/Microservices. Hỗ trợ HTTP/2, gRPC, observability tốt.CloudflareDịch vụ Reverse Proxy dạng SaaS (không cần tự cài đặt). Có thêm CDN, DDoS protection tích hợp.

2. Load Balancer - LB (Người chia việc)

2.1. Khái niệm

Khi ứng dụng đông người dùng, 1 con server không thể gánh hết. Anh em phải chạy nhiều bản sao (instance/replica) của backend server.
Load Balancer đứng giữa nhận toàn bộ traffic đầu vào và phân phối đều cho các server đằng sau, đảm bảo không con nào bị quá tải trong khi con khác đang ngồi chơi.

2.2. Phân loại theo tầng hoạt động (OSI Model)

a) Layer 4 Load Balancer (Tầng Transport — TCP/UDP)

Hoạt động ở tầng mạng thấp. Nó chỉ nhìn vào thông tin IP nguồn/đích và port, rồi quyết định chuyển gói tin tới server nào.
Không đọc được nội dung HTTP (không biết URL là gì, header thế nào).
Ưu điểm: Cực kỳ nhanh, overhead gần như bằng 0 vì không cần giải mã nội dung.
Nhược điểm: "Mù" về nội dung, không thể routing theo URL hay cookie.
Ví dụ thực tế: AWS NLB (Network Load Balancer), HAProxy (chế độ TCP mode).

b) Layer 7 Load Balancer (Tầng Application — HTTP/HTTPS)

Hoạt động ở tầng ứng dụng. Nó đọc được toàn bộ nội dung HTTP: URL path, header, cookie, body.
Có thể routing thông minh: ví dụ request có URL /api/images/* thì đẩy sang cụm server xử lý ảnh, còn /api/users/* thì đẩy sang cụm server user.
Ưu điểm: Linh hoạt, routing chính xác theo nội dung.
Nhược điểm: Chậm hơn L4 một chút vì phải đọc và phân tích nội dung HTTP.
Ví dụ thực tế: AWS ALB (Application Load Balancer), Nginx, HAProxy (HTTP mode).

2.3. Các thuật toán cân bằng tải chi tiết

Thuật toánCách hoạt độngKhi nào nên dùngRound RobinChia luân phiên theo vòng tròn: S1 → S2 → S3 → S1...Khi các server cùng cấu hình phần cứng giống nhau.Weighted Round RobinGiống Round Robin nhưng server mạnh hơn được gán trọng số cao hơn (nhận nhiều request hơn). Ví dụ S1 (weight=3) nhận 3 request, S2 (weight=1) nhận 1 request.Khi các server có cấu hình khác nhau.Least ConnectionsĐẩy request vào server đang có ít kết nối đang xử lý nhất tại thời điểm hiện tại.Khi các request có thời gian xử lý khác nhau nhiều (ví dụ API upload file lớn xen lẫn API đọc data nhẹ).Weighted Least ConnectionsKết hợp Least Connections + trọng số server.Khi server khác cấu hình + request khác nhau về độ nặng.IP HashHash IP của Client để xác định server. Cùng 1 IP luôn được trỏ vào cùng 1 server.Khi cần giữ session (sticky session) mà không muốn dùng session store bên ngoài.Least Response TimeĐẩy request vào server có thời gian phản hồi trung bình thấp nhất.Khi muốn tối ưu trải nghiệm người dùng, ưu tiên server phản hồi nhanh nhất.RandomChọn ngẫu nhiên 1 server.Đơn giản, ít dùng ở production nghiêm túc.

2.4. Health Check (Kiểm tra sức khỏe server)

Load Balancer liên tục gửi các tín hiệu kiểm tra (ping) đến các server backend để biết chúng có còn sống không.
Có 2 loại:
- Active Health Check: LB chủ động gửi request kiểm tra định kỳ (ví dụ mỗi 5 giây gọi GET /health vào backend, nếu response 200 thì OK, nếu timeout hoặc 500 thì đánh dấu server đó là "down").
- Passive Health Check: LB theo dõi các request thật từ người dùng. Nếu thấy 1 server liên tục trả lỗi 502/503 thì tự động coi server đó là "down".
Khi server bị đánh dấu "down", LB sẽ ngừng gửi traffic vào server đó. Khi server đó phục hồi (health check trả về OK), LB tự động đưa nó trở lại danh sách phục vụ.

2.5. Session Persistence (Sticky Session)

Vấn đề: Nếu user A gửi request 1 vào Server 1, rồi request 2 bị LB đẩy sang Server 2, thì session đăng nhập trên Server 1 sẽ bị mất.
Giải pháp 1 - Sticky Session: Dùng cookie hoặc IP Hash để đảm bảo cùng 1 user luôn được trỏ về cùng 1 server. Nhược điểm: nếu server đó chết thì user mất session.
Giải pháp 2 - External Session Store (tốt hơn): Lưu session vào một nơi chung như Redis, Memcached hoặc Database. Mọi server đều đọc/ghi session tại cùng 1 nơi. User có thể bị đẩy vào bất kỳ server nào cũng không bị mất session.

2.6. Công cụ phổ biến

Công cụĐặc điểmHAProxyMã nguồn mở, hiệu suất cao, hỗ trợ cả L4 và L7. Rất phổ biến ở Linux server.NginxVừa làm Reverse Proxy vừa làm LB. Cấu hình dễ hiểu.AWS ELBDịch vụ managed của AWS, gồm 3 loại: ALB (L7), NLB (L4), GLB (Gateway LB). Không cần tự quản lý server.Google Cloud Load BalancingTương tự AWS, dạng managed, global scale.TraefikTự động phát hiện service mới (dùng nhiều với Docker/Kubernetes).

3. API Gateway (Lễ tân tòa nhà)

3.1. Khái niệm

Khi hệ thống từ kiến trúc Monolith chuyển sang Microservices (chia nhỏ app thành hàng chục service riêng biệt: User Service, Order Service, Payment Service, Notification Service...), sẽ phát sinh 2 vấn đề lớn:
- Client phải biết địa chỉ của từng service → rối, khó maintain.
- Mỗi service phải tự cài logic bảo mật, rate limit, logging → trùng lặp code, dễ sai sót.
API Gateway giải quyết cả 2 vấn đề trên bằng cách tạo ra một cổng vào duy nhất (Single Entry Point) cho toàn bộ hệ thống. Client chỉ cần biết 1 địa chỉ duy nhất, mọi thứ phía sau do Gateway lo.

3.2. Cơ chế hoạt động chi tiết

Client gửi request tới https://api.myapp.com/orders/123.
API Gateway nhận request, thực hiện một chuỗi kiểm tra theo thứ tự (gọi là Request Pipeline):
- Bước 1: Kiểm tra Rate Limit → user này đã vượt quá giới hạn chưa?
- Bước 2: Authentication → token JWT có hợp lệ không? Hết hạn chưa?
- Bước 3: Authorization → user này có quyền truy cập resource /orders/123 không?
- Bước 4: Request Transformation → sửa header, thêm metadata nội bộ, validate body.
- Bước 5: Routing → path /orders/* khớp với rule chuyển tới Order Service.
API Gateway forward request tới order-service:8080/orders/123.
Order Service xử lý và trả kết quả về API Gateway.
API Gateway thực hiện Response Pipeline: thêm CORS header, log response, transform data format nếu cần, rồi trả response cho Client.

3.3. Các chức năng kỹ thuật quan trọng

a) Authentication & Authorization (Xác thực & Phân quyền)

Gateway kiểm tra tính hợp lệ của JWT token, API Key, OAuth2 access token.
Hỗ trợ nhiều phương thức xác thực: JWT, OAuth2, Basic Auth, HMAC, mTLS (mutual TLS).
Sau khi xác thực, Gateway có thể inject thông tin user vào header (X-User-ID, X-User-Role) để các service downstream sử dụng mà không cần tự decode token nữa.

b) Rate Limiting & Throttling (Giới hạn tốc độ gọi)

Áp dụng giới hạn theo nhiều chiều:
- Theo user: "User A chỉ được gọi 100 request/phút".
- Theo API endpoint: "Endpoint /api/login chỉ cho phép 10 request/phút/IP".
- Theo plan/tier: "User ở gói Free giới hạn 1000 req/ngày, gói Premium giới hạn 100000 req/ngày".
Các thuật toán Rate Limiting phổ biến:
- Token Bucket: Mỗi user có một bucket chứa token. Mỗi request tiêu tốn 1 token. Token được bổ sung đều đặn theo thời gian. Hết token thì bị chặn.
- Sliding Window: Đếm số request trong 1 cửa sổ thời gian trượt.
- Fixed Window: Đếm số request trong 1 khung thời gian cố định (ví dụ mỗi phút reset về 0).

c) Request/Response Transformation (Biến đổi dữ liệu)

Thay đổi header, body, query params trước khi forward vào backend.
Ví dụ thực tế: Client gửi lên JSON, nhưng backend cũ chỉ hiểu XML → Gateway có thể chuyển đổi format.
Hoặc backend trả về 20 trường data nhưng Client mobile chỉ cần 5 trường → Gateway lọc bớt response cho nhẹ.

d) API Composition / Aggregation (Gộp API)

Đây là tính năng mạnh và khác biệt nhất so với Reverse Proxy và LB.
Ví dụ: Client cần hiển thị trang "Chi tiết đơn hàng" gồm thông tin đơn hàng + thông tin user + trạng thái thanh toán. Thay vì bắt Client gọi 3 API riêng rẽ (tốn 3 round-trip), Gateway có thể tự gọi song song 3 service bên trong, gom kết quả lại thành 1 response duy nhất rồi trả về → giảm latency cho Client rất nhiều.

e) Circuit Breaker (Cầu dao ngắt mạch)

Khi 1 service bên trong bị chết hoặc phản hồi quá chậm, Gateway tạm thời ngắt kết nối đến service đó luôn (không gọi nữa). Sau một khoảng thời gian (ví dụ 30 giây), nó thử gọi lại xem service đã khỏe chưa.
Mục đích: Tránh hiệu ứng domino — 1 service chết kéo theo toàn bộ hệ thống sập vì tất cả request đều bị kẹt chờ ở service chết đó.
Pattern này lấy cảm hứng từ cầu dao điện trong nhà: khi có sự cố thì ngắt mạch để bảo vệ toàn bộ hệ thống.

f) Service Discovery (Tự tìm service)

Trong môi trường container (Docker, Kubernetes), IP của các service thay đổi liên tục (container bị kill rồi tạo lại sẽ có IP mới).
API Gateway có thể tích hợp với hệ thống Service Discovery (như Consul, Eureka, Kubernetes DNS) để tự động biết service nào đang chạy ở đâu mà không cần config IP cứng.

g) Logging, Monitoring & Analytics

Gateway là điểm duy nhất mà mọi request đều đi qua, nên nó là nơi rất lý tưởng để:
- Ghi log tập trung (centralized logging).
- Đo lường latency, error rate, request count cho từng API.
- Tracing — gắn Trace ID vào mỗi request để theo dõi nó đi qua bao nhiêu service.
- Xuất metrics lên Grafana, Prometheus, Datadog...

h) API Versioning (Quản lý phiên bản API)

Khi cần ra API mới mà không muốn phá vỡ app cũ: Gateway có thể routing /v1/users sang service cũ, /v2/users sang service mới.
Hoặc dùng header Accept-Version: v2 để xác định version.

3.4. Các pattern nâng cao

a) BFF Pattern (Backend For Frontend)

Thay vì dùng 1 API Gateway cho tất cả loại Client, anh em tạo nhiều Gateway riêng:
- Gateway cho Mobile (trả data nhẹ, ít trường, hình ảnh nén).
- Gateway cho Web (trả đầy đủ data, hỗ trợ SSR).
- Gateway cho IoT/Thiết bị nhúng (protocol khác, data tối giản).
Mỗi Gateway này được tối ưu riêng cho loại Client tương ứng.

b) Sidecar / Service Mesh

Ở hệ thống cực lớn, thay vì dồn hết logic vào 1 con API Gateway trung tâm (dễ thành điểm nghẽn - bottleneck), anh em có thể dùng mô hình Service Mesh (ví dụ Istio, Linkerd).
Mỗi service sẽ được gắn kèm 1 proxy nhỏ (gọi là Sidecar, thường là Envoy), Sidecar này lo hết việc bảo mật, routing, retry, circuit breaker ở cấp độ từng service. Gateway trung tâm lúc này chỉ còn lo xác thực ban đầu và routing tầng ngoài.

3.5. Công cụ phổ biến

Công cụĐặc điểmKongMã nguồn mở, dựa trên Nginx + Lua. Hệ sinh thái plugin rất phong phú. Quản lý bằng Admin API hoặc dashboard.AWS API GatewayDịch vụ managed của AWS. Tích hợp sâu với Lambda, IAM, Cognito. Trả phí theo số lượng request.TraefikTự động discovery service từ Docker/Kubernetes. Cấu hình bằng label, rất tiện cho cloud-native.Apigee (Google)Enterprise-grade, mạnh về analytics, developer portal, API monetization.OcelotDành riêng cho hệ sinh thái .NET. Nhẹ, dễ tích hợp vào project ASP.NET Core.KrakenDHiệu suất cao, stateless (không cần database), cấu hình bằng JSON/YAML.TykMã nguồn mở, viết bằng Go, hỗ trợ GraphQL gateway.

4. So sánh chi tiết: Điểm giống và khác nhau

4.1. Điểm giống nhau

Cả 3 đều nằm ở giữa (Middle-man) làm trung gian giữa Client và Backend Server.
Cả 3 đều nhận request từ Client và chuyển tiếp (forward/proxy) nó đi nơi khác.
Cả 3 đều có thể giúp ẩn danh backend — Client không biết chính xác server thật nằm ở đâu.
Cả 3 đều có thể hoạt động ở tầng 7 (HTTP/HTTPS).
Nhiều công cụ có thể đảm nhận cả 3 vai trò cùng lúc (Nginx, Traefik, Envoy...). Đây chính là lý do dễ nhầm lẫn nhất.

4.2. Điểm khác nhau cốt lõi

Tiêu chíReverse ProxyLoad BalancerAPI GatewayMục đích chínhẨn danh server, bảo mật, SSL termination, caching nội dung tĩnh.Phân phối đều traffic cho nhóm server giống nhau để xử lý tải cao.Quản lý toàn bộ vòng đời API: xác thực, phân quyền, rate limit, routing tới đúng microservice.Tầng hoạt động (OSI)Tầng 7 (Application).Tầng 4 (TCP/UDP) hoặc Tầng 7 (HTTP).Luôn ở Tầng 7 (Application). Hiểu sâu logic ứng dụng.Đọc/sửa nội dung request?Giới hạn (nén, thêm header cơ bản).L4: Không. L7: Đọc được nhưng ít khi sửa.Có. Đọc sâu, validate, transform body, gộp response từ nhiều service.Biết về nhiều loại backend service khác nhau?Thường chỉ biết 1 nhóm server.Biết 1 nhóm server giống nhau (cùng chạy 1 app).Biết nhiều nhóm service khác nhau (User, Order, Payment...) và routing tới đúng nhóm.AuthenticationKhông (hoặc rất cơ bản).Không.Có — JWT, OAuth2, API Key...Rate LimitingCó thể cấu hình cơ bản.Không.Có — chi tiết theo user, endpoint, plan.Circuit BreakerKhông.Không (chỉ có Health Check).Có.API AggregationKhông.Không.Có — gộp nhiều API thành 1 response.Mức độ phức tạp vận hànhThấp.Trung bình.Cao (cần quản lý plugin, policy, monitoring).

4.3. Cách phân biệt dễ nhớ

Reverse Proxy → trả lời câu hỏi: "Làm sao che giấu và bảo vệ backend?"
Load Balancer → trả lời câu hỏi: "Làm sao chia đều việc khi có quá nhiều người dùng?"
API Gateway → trả lời câu hỏi: "Làm sao quản lý, kiểm soát và điều phối hàng chục microservices một cách có tổ chức?"

5. Bức tranh toàn cảnh khi kết hợp cả 3

Nếu nhìn vào các hệ thống lớn ở production, họ thường kết hợp cả 3 thành phần thành một kiến trúc nhiều lớp:

                             ┌───────────────────────────────────┐
                             │          CDN / Edge Layer         │
                             │  (Cloudflare, AWS CloudFront)     │
                             │  Cache static content, DDoS       │
                             └────────────────┬──────────────────┘
                                              │
                             ┌────────────────▼──────────────────┐
                             │    Global Load Balancer (L4)      │
                             │  (AWS NLB, Google Cloud LB)       │
                             │  Phân tải TCP/IP cực nhanh        │
                             └───────┬───────────────┬───────────┘
                                     │               │
                          ┌──────────▼─────┐  ┌──────▼──────────┐
                          │  API Gateway   │  │  API Gateway    │
                          │  Instance 1    │  │  Instance 2     │
                          │  (Kong/Traefik)│  │  (Kong/Traefik) │
                          │  Auth, Rate    │  │  Auth, Rate     │
                          │  Limit, Route  │  │  Limit, Route   │
                          └──┬────┬────┬───┘  └──┬────┬────┬────┘
                             │    │    │          │    │    │
              ┌──────────────▼┐ ┌─▼──┐ ┌▼────┐   │    │    │
              │ User Service  │ │Order│ │Pay- │   │    │    │
              │ (3 replicas)  │ │Svc  │ │ment │   ...  ...  ...
              │ + Internal LB │ │     │ │Svc  │
              └───────────────┘ └─────┘ └─────┘

Luồng request đi qua hệ thống:

CDN / Edge Layer: Nếu request là file tĩnh (ảnh, CSS, JS), CDN trả về luôn từ edge server gần nhất. Nếu là API request, chuyển tiếp xuống.
Global Load Balancer (L4): Nhận kết nối TCP, chia đều sang nhiều instance API Gateway.
API Gateway: Kiểm tra token, rate limit, routing vào đúng microservice.
Microservices: Mỗi service có thể có internal LB riêng để cân bằng tải giữa các replica của chính nó.

6. Các tình huống thực tế và lựa chọn

Tình huốngNên dùng gì?Giải thíchWeb app nhỏ, 1 server backend, muốn có HTTPSReverse Proxy (Nginx hoặc Caddy)Chỉ cần che IP, thêm SSL, có thể thêm caching. Chưa cần LB hay Gateway.Web app trung bình, traffic tăng, cần chạy nhiều instance backendReverse Proxy + Load Balancer (Nginx cấu hình upstream)Nginx vừa làm Reverse Proxy vừa làm LB. Một công cụ giải quyết 2 việc.Hệ thống microservices, nhiều team, nhiều service khác nhauLoad Balancer + API GatewayLB chia tải ở tầng ngoài, API Gateway quản lý routing, auth, rate limit cho từng service.Hệ thống lớn, cần chịu tải global, nhiều loại Client (mobile, web, IoT)CDN + LB + API Gateway (nhiều instance) + Internal LBKiến trúc đầy đủ nhiều lớp như sơ đồ ở trên.

7. Những lưu ý khi triển khai thực tế

API Gateway là Single Point of Failure (SPOF): Nếu chỉ chạy 1 instance Gateway mà nó chết thì toàn bộ hệ thống mất kết nối. Nên luôn luôn chạy ít nhất 2 instance Gateway và đặt 1 con LB phía trước chúng.
Đừng nhồi quá nhiều logic vào Gateway: Gateway nên làm những thứ cross-cutting (xác thực, rate limit, logging). Đừng nhét business logic vào đây vì sẽ biến nó thành một monolith mới.
Caching cẩn thận: Cache sai thì user nhận được data cũ (stale data), đặc biệt nguy hiểm với dữ liệu thanh toán, giỏ hàng. Chỉ nên cache những data ít thay đổi (danh sách sản phẩm, hình ảnh, file tĩnh).
Health Check phải test đúng thứ cần test: Đừng chỉ check xem server có trả 200 OK không. Nên kiểm tra cả kết nối database, Redis, disk space... (gọi là Deep Health Check).
Observability: Khi hệ thống phức tạp với nhiều lớp, việc debug sẽ rất khó nếu không có Distributed Tracing (ví dụ Jaeger, Zipkin). Gắn Trace ID vào mỗi request từ tầng Gateway để khi có lỗi, anh em biết request đó đã đi qua những service nào.

Nắm vững bản chất của bộ ba này, anh em sẽ tự tin hơn khi thiết kế hạ tầng backend dù là project nhỏ hay hệ thống quy mô lớn.