Chương 42. API Gateway

Chương trước ta nói về:

Reverse proxy.
Load balancer.

Chúng là lớp cửa trước rất phổ biến của production web app.

Chương này nói về một khái niệm gần đó nhưng không hoàn toàn giống:

API Gateway.

API Gateway cũng đứng trước backend.

Nhưng thường nó không chỉ chuyển tiếp request.

Nó còn có thể làm:

  • Routing request đến nhiều service.
  • Authentication ở cửa vào.
  • Rate limiting.
  • API key management.
  • Request/response transformation.
  • Request aggregation.
  • Versioning.
  • Logging/metrics.
  • Policy enforcement.
  • Backend for Frontend.

Thông điệp chính của chương:

> API Gateway hữu ích khi hệ thống có nhiều API/service/client và cần một cửa điều phối rõ ràng. Nhưng nếu nhét quá nhiều business logic vào gateway, nó sẽ thành điểm nghẽn và làm hệ thống khó hiểu.

---

42.1. Ví dụ dễ hiểu: quầy điều phối trong bệnh viện

Một bệnh viện có nhiều khoa:

  • Khoa khám tổng quát.
  • Khoa xét nghiệm.
  • Khoa chẩn đoán hình ảnh.
  • Khoa thanh toán.
  • Khoa thuốc.

Bệnh nhân không tự đi từng phòng hỏi:

Tôi nên vào đâu?
Tôi cần giấy gì?
Tôi có được khám dịch vụ này không?
Tôi phải trả phí thế nào?

Thường có một quầy điều phối.

Quầy này:

  • Nhận yêu cầu.
  • Kiểm tra thông tin cơ bản.
  • Chuyển đến đúng khoa.
  • Có thể gom thông tin từ nhiều nơi.
  • Giảm việc bệnh nhân phải hiểu cấu trúc bên trong bệnh viện.

API Gateway cũng tương tự.

Client không cần biết bên trong có bao nhiêu service.

Client gọi một cửa API.

Gateway điều phối phía sau.

---

42.2. API Gateway là gì?

API Gateway là lớp đứng trước một hoặc nhiều backend service để quản lý traffic API.

Luồng:

Client
-> API Gateway
-> Service A / Service B / Service C

Ví dụ:

Mobile app gọi /api/me/dashboard
Gateway nhận request
Gateway xác thực token
Gateway gọi User Service, Course Service, Submission Service
Gateway trả response phù hợp cho mobile

Ở mức đơn giản, API Gateway có thể chỉ route path:

/users/*       -> User Service
/courses/*     -> Course Service
/submissions/* -> Submission Service
/billing/*     -> Billing Service

Ở mức phức tạp hơn, nó có thể xử lý policy và composition.

---

42.3. API Gateway khác reverse proxy ở đâu?

Reverse proxy thường tập trung vào HTTP forwarding:

  • Nhận request.
  • Chuyển vào upstream.
  • TLS.
  • Timeout.
  • Static files.
  • Header.
  • Access log.

API Gateway thường thêm lớp quản lý API:

  • Authentication.
  • Authorization ở mức coarse-grained.
  • Rate limit theo user/API key/tenant.
  • Route tới nhiều service.
  • API version.
  • Request validation.
  • Response transformation.
  • Request aggregation.
  • Developer portal/API key nếu là public API.

Trong thực tế, ranh giới không tuyệt đối.

Một Nginx/Envoy/Kong/Traefik có thể làm nhiều việc gateway.

Một cloud API Gateway cũng làm reverse proxy.

Điểm quan trọng:

> Reverse proxy là cửa chuyển tiếp HTTP. API Gateway là cửa chính sách và điều phối API.

---

42.4. Khi nào chưa cần API Gateway?

Nếu hệ thống còn đơn giản:

Frontend -> Backend monolith

Bạn có thể chưa cần API Gateway riêng.

Reverse proxy/load balancer là đủ.

Ví dụ:

Cloudflare/Nginx
-> Django/FastAPI monolith
-> PostgreSQL

Nếu chỉ có một backend, một frontend, auth nằm trong backend, rate limit đơn giản, routing không phức tạp:

API Gateway riêng có thể là quá sớm.

Đừng thêm gateway chỉ vì nghe giống microservices.

---

42.5. Khi nào API Gateway bắt đầu có ích?

API Gateway có ích khi:

  • Có nhiều backend service.
  • Có nhiều loại client: web, mobile, partner API.
  • Cần auth/rate limit ở cửa vào.
  • Cần API key cho bên thứ ba.
  • Cần route theo path/host/version.
  • Cần gom nhiều service thành một response.
  • Cần che cấu trúc service nội bộ.
  • Cần policy nhất quán cho API public.
  • Cần logging/metrics tập trung ở edge API.

Ví dụ:

Web app
Mobile app
Admin app
Partner LMS integration

tất cả gọi vào một nền tảng AI Judge.

Lúc này gateway có thể giúp tổ chức API rõ hơn.

---

42.6. Routing request đến nhiều service

Routing là nhiệm vụ cơ bản của gateway.

Ví dụ:

/api/users/*        -> User Service
/api/courses/*      -> Course Service
/api/assignments/*  -> Assignment Service
/api/submissions/*  -> Submission Service
/api/grading/*      -> Grading Service
/api/billing/*      -> Billing Service

Client gọi cùng một domain:

https://api.synvia.com/api/submissions/123

Gateway chuyển đến service đúng.

Lợi ích:

  • Client không cần biết hostname nội bộ.
  • Có một cửa public rõ.
  • Dễ đổi service bên trong hơn.
  • Dễ áp dụng policy chung.

Nhưng routing cũng cần quản lý tốt.

Nếu route rule nhiều và rối, debug sẽ khó.

---

42.7. Che cấu trúc nội bộ

Không nên bắt client biết:

user-service.internal
course-service.internal
grading-service.internal
billing-service.internal

Client nên thấy API ổn định:

api.synvia.com

Bên trong bạn có thể đổi:

Submission logic từ monolith tách sang service.
Grading service đổi hostname.
Billing service chuyển provider.

Nếu API contract bên ngoài giữ nguyên, client ít bị ảnh hưởng.

Gateway giúp tách:

Public API shape

khỏi:

Internal service topology

---

42.8. Authentication ở gateway

Gateway có thể kiểm tra authentication trước khi request vào backend.

Ví dụ:

Client gửi Authorization: Bearer <token>
Gateway verify token.
Nếu token không hợp lệ, trả 401.
Nếu hợp lệ, forward request vào service.

Lợi ích:

  • Chặn request không hợp lệ sớm.
  • Backend service giảm lặp logic verify token.
  • Logging auth failure tập trung.
  • Có thể chuẩn hóa user context header.

Nhưng cẩn thận:

> Gateway xác thực user là ai không có nghĩa backend khỏi kiểm tra authorization.

Backend/service vẫn phải kiểm tra object-level permission.

Gateway thường chỉ làm auth chung.

Domain service mới biết rule nghiệp vụ cụ thể.

---

42.9. Authorization ở gateway nên ở mức nào?

Gateway có thể làm authorization thô.

Ví dụ:

Chỉ admin role được gọi /admin/*
Chỉ service token được gọi /internal/*
API key partner chỉ được gọi /partner/*

Nhưng gateway không nên ôm quá nhiều rule domain chi tiết.

Ví dụ không nên để gateway quyết định phức tạp:

Teacher A có được chấm submission_123 không?
Student B có được tải feedback file_456 không?
Assignment đã khóa chưa?

Vì những thông tin đó nằm trong domain/database của service.

Tư duy:

Gateway:
  auth chung, scope/role thô, rate limit, route.

Service:
  permission nghiệp vụ, object-level check, tenant rule chi tiết.

---

42.10. Forward user context

Sau khi gateway verify token, nó có thể forward thông tin user vào backend.

Ví dụ:

X-User-Id: user_9
X-Tenant-Id: school_A
X-User-Roles: teacher

Nhưng phải rất cẩn thận.

Backend chỉ nên tin header này nếu:

  • Request thật sự đến từ gateway tin cậy.
  • Client bên ngoài không thể set header trực tiếp.
  • Gateway xóa các header giả từ client.
  • Mạng/internal routing chặn bypass gateway.

Nếu không, attacker có thể tự gửi:

X-User-Id: admin

và backend bị lừa.

Cách an toàn hơn trong nhiều hệ thống:

Gateway forward token đã verify hoặc token nội bộ đã ký.
Backend verify hoặc tin qua mTLS/trusted network nghiêm túc.

---

42.11. Rate limiting ở gateway

Rate limit ở gateway rất hữu ích.

Vì gateway là cửa trước, nó có thể giới hạn trước khi request đập vào service.

Ví dụ:

100 request/phút/user
1.000 request/phút/tenant
10 request/phút/IP cho login
50 grading requests/giờ/API key

Rate limit ở gateway giúp:

  • Chống abuse.
  • Bảo vệ service phía sau.
  • Giảm traffic xấu sớm.
  • Quản lý quota API public.

Nhưng rate limit cần chọn key đúng:

  • IP.
  • User.
  • Tenant.
  • API key.
  • Route.
  • Combination.

Sai key có thể gây oan hoặc lọt abuse.

---

42.12. Rate limit ở gateway không thay thế quota nghiệp vụ

Gateway có thể giới hạn tốc độ.

Nhưng quota nghiệp vụ nhiều khi cần backend.

Ví dụ:

Tenant A được chấm 10.000 bài/tháng.
Course B chỉ được export 20 report/ngày.
User C được upload tối đa 2 GB.

Những quota này cần dữ liệu nghiệp vụ.

Gateway có thể không biết đủ.

Vì vậy:

Gateway rate limit:
  bảo vệ cửa vào, chống tốc độ bất thường.

Backend quota:
  kiểm soát tài nguyên theo nghiệp vụ.

Đừng dồn hết quota vào gateway nếu gateway không có context.

---

42.13. API key management

Nếu bạn mở API cho partner, gateway có thể quản lý API key.

Ví dụ:

LMS partner gọi API tạo assignment.
School system đồng bộ danh sách học sinh.
External integration lấy kết quả.

Gateway có thể:

  • Verify API key.
  • Gắn partner identity.
  • Rate limit theo key.
  • Log usage.
  • Enforce scope.
  • Revoke key.

Ví dụ:

api_key_X:
  owner = school_A_lms
  scopes = assignment.read, roster.sync
  rate_limit = 1000/hour

Backend vẫn cần kiểm tra action cụ thể và tenant boundary.

Gateway chỉ là lớp đầu.

---

42.14. Request validation

Gateway có thể validate request ở mức cơ bản.

Ví dụ:

  • Body quá lớn thì reject.
  • Method không được phép thì reject.
  • Missing required header.
  • Content-Type không hợp lệ.
  • JSON malformed.
  • API schema validation cơ bản.

Lợi ích:

  • Chặn request xấu sớm.
  • Giảm tải backend.
  • Chuẩn hóa lỗi.

Nhưng validate nghiệp vụ chi tiết vẫn nên ở backend.

Ví dụ:

assignment_id có tồn tại không?
user có enrolled không?
deadline còn không?

Gateway không nên phải biết hết.

---

42.15. Request/response transformation

Gateway có thể biến đổi request/response.

Ví dụ:

Đổi header.
Đổi path.
Thêm correlation id.
Map field cũ sang field mới.
Chuẩn hóa error format.

Điều này tiện khi:

  • Giữ compatibility với client cũ.
  • Di chuyển service nội bộ.
  • Chuẩn hóa API public.

Nhưng transformation quá nhiều là dấu hiệu nguy hiểm.

Nếu gateway phải hiểu sâu payload nghiệp vụ, debug sẽ khó.

Rule thực dụng:

> Gateway có thể transform kỹ thuật nhẹ. Business transformation nên nằm ở service hoặc BFF rõ ràng.

---

42.16. Request aggregation là gì?

Request aggregation là gateway gọi nhiều backend rồi gom thành một response.

Ví dụ mobile app cần dashboard:

User profile
Courses
Recent submissions
Pending grading jobs
Notifications

Nếu mobile tự gọi 5 API, latency tăng và logic client phức tạp.

Gateway/BFF có thể cung cấp:

GET /mobile/dashboard

Bên trong:

Call User Service
Call Course Service
Call Submission Service
Call Notification Service
Gom response
Trả về mobile

Aggregation giúp client đơn giản hơn.

Nhưng gateway phải xử lý failure/timeout/caching cẩn thận.

---

42.17. Aggregation có rủi ro gì?

Nếu endpoint aggregate gọi 5 service, nó có 5 điểm có thể chậm/lỗi.

Ví dụ:

Notification Service timeout.
Dashboard mobile có lỗi toàn bộ không?
Hay vẫn trả profile/courses và thiếu notifications?

Cần quyết định:

  • Dependency nào bắt buộc?
  • Dependency nào optional?
  • Timeout từng service bao nhiêu?
  • Có fallback không?
  • Có cache phần nào không?
  • Error response thế nào?

Aggregation làm client dễ hơn nhưng server phải chịu complexity.

Không nên gom mọi thứ vào một endpoint khổng lồ nếu không có lý do rõ.

---

42.18. Backend for Frontend là gì?

Backend for Frontend, viết tắt BFF, là backend/gateway riêng cho từng loại frontend.

Ví dụ:

Web BFF
Mobile BFF
Admin BFF
Partner API

Mỗi client có nhu cầu khác nhau.

Mobile cần payload nhỏ, ít round trip.

Web admin cần dữ liệu chi tiết hơn.

Partner API cần contract ổn định và hạn chế scope.

BFF giúp tránh một API phải phục vụ mọi client theo cách rối.

---

42.19. BFF khác API Gateway chung thế nào?

API Gateway chung thường làm cửa vào kỹ thuật:

  • Auth.
  • Rate limit.
  • Routing.
  • Logging.

BFF tập trung vào trải nghiệm client cụ thể:

  • Shape response cho mobile.
  • Aggregate dữ liệu cho web.
  • Hide field không cần.
  • Optimize payload.
  • Map flow riêng cho admin.

Có thể triển khai BFF như một service riêng phía sau gateway.

Luồng:

Mobile App
-> API Gateway
-> Mobile BFF
-> Domain services

Không bắt buộc phải có BFF từ đầu.

Nhưng khi web/mobile/admin có nhu cầu rất khác nhau, BFF rất hữu ích.

---

42.20. GraphQL có phải API Gateway không?

GraphQL có thể đóng vai trò giống gateway/BFF.

Client gửi query:

Tôi cần user, courses, submissions.

GraphQL server gọi nhiều nguồn dữ liệu và trả đúng shape client cần.

Điểm mạnh:

  • Client linh hoạt.
  • Tránh over-fetch/under-fetch.
  • Hợp khi nhiều frontend cần shape khác nhau.

Điểm cần cẩn thận:

  • N+1 query.
  • Authorization field-level/object-level.
  • Query quá nặng.
  • Caching khó hơn REST đơn giản.
  • Rate limit theo complexity.

GraphQL không tự động thay API Gateway.

Nó là một cách xây API layer/BFF mạnh, nhưng cần kỷ luật.

---

42.21. API versioning

Gateway có thể giúp route version API.

Ví dụ:

/api/v1/*
/api/v2/*

Hoặc theo header:

Accept: application/vnd.synvia.v2+json

Versioning quan trọng khi có client ngoài không update cùng lúc.

Ví dụ:

Mobile app cũ vẫn dùng v1.
Web app mới dùng v2.
Partner integration cần thời gian migrate.

Gateway có thể route v1/v2 đến service khác hoặc adapter khác.

Nhưng versioning cũng tạo chi phí.

Đừng tạo version mới cho mọi thay đổi nhỏ.

---

42.22. Developer portal và public API

Nếu sản phẩm có public API cho developer/partner, gateway có thể đi cùng:

  • API key creation.
  • Documentation.
  • Usage dashboard.
  • Rate limit plan.
  • Scope.
  • Billing.
  • Sandbox.
  • Webhook config.

Ví dụ:

School LMS integration dùng API Synvia.

Partner cần biết:

  • Endpoint nào.
  • Auth thế nào.
  • Rate limit bao nhiêu.
  • Error format.
  • Webhook event nào.

API Gateway không chỉ là routing.

Với public API, nó trở thành một phần của product surface.

---

42.23. Observability ở gateway

Gateway thấy toàn bộ traffic vào API.

Nó nên ghi:

  • Request count.
  • Latency.
  • Status code.
  • Route.
  • Client/user/API key.
  • Rate limit hit.
  • Upstream service latency.
  • Error rate.
  • Request size.

Gateway metrics giúp trả lời:

  • Endpoint nào bị gọi nhiều?
  • Service nào chậm?
  • Partner nào vượt quota?
  • 401/403 tăng ở đâu?
  • 5xx đến từ gateway hay upstream?

Nhưng đừng log secret/token/body nhạy cảm.

Gateway là nơi rất dễ vô tình ghi quá nhiều.

---

42.24. Correlation ID ở gateway

Gateway là nơi tốt để tạo hoặc chuẩn hóa request id.

Ví dụ:

X-Request-Id: req_abc

Gateway nhận request.

Nếu client chưa có request id, gateway tạo.

Sau đó forward vào các service.

Mỗi service log cùng request id.

Khi lỗi xảy ra:

Tìm req_abc trong gateway log, service log, worker log.

Correlation ID làm hệ thống nhiều service dễ debug hơn.

---

42.25. Gateway timeout

Giống reverse proxy, API Gateway cũng có timeout.

Nếu gateway timeout 30 giây mà backend xử lý 60 giây:

Client nhận timeout.
Backend có thể vẫn chạy.

Đối với việc lâu:

  • Chấm bài AI.
  • Export report.
  • Upload lớn.
  • Video processing.
  • Bulk import.

nên dùng job nền.

Gateway nên nhận request nhanh, trả status rõ:

202 Accepted
job_id
status_url

Đừng biến gateway thành nơi chờ việc dài.

---

42.26. Gateway có thể thành single point of failure

Nếu mọi request đi qua gateway, gateway lỗi là toàn hệ thống bị ảnh hưởng.

Vì vậy gateway cần:

  • High availability.
  • Health check.
  • Autoscaling.
  • Monitoring.
  • Rollback config.
  • Config test.
  • Rate limit store ổn định.
  • Safe deploy.

Gateway config sai có thể làm nhiều service cùng lỗi.

Ví dụ:

Route /api/submissions/* trỏ nhầm service.
JWT issuer config sai.
Rate limit quá chặt.
CORS allowlist thiếu domain production.

Gateway mạnh, nên sai cũng mạnh.

---

42.27. Gateway trở thành điểm nghẽn khi nào?

Gateway có thể nghẽn khi:

  • Tất cả traffic đi qua một cụm quá nhỏ.
  • TLS/auth verification quá nặng.
  • Rate limit state chậm.
  • Aggregation gọi nhiều service chậm.
  • Transformation payload lớn.
  • Logging quá nhiều.
  • Plugin/middleware quá dày.
  • Config route quá phức tạp.

Nếu gateway chỉ route và policy nhẹ, thường ổn.

Nếu gateway bắt đầu làm business logic nặng, nó dễ thành bottleneck.

Rule:

> Gateway nên mỏng vừa đủ. Logic nghiệp vụ sâu nên ở service/domain.

---

42.28. Gateway không nên thành distributed monolith mới

Một lỗi kiến trúc:

Tách microservices.
Sau đó nhét toàn bộ logic phối hợp vào gateway.

Kết quả:

  • Service nhỏ nhưng gateway khổng lồ.
  • Mọi thay đổi phải sửa gateway.
  • Gateway hiểu hết domain.
  • Team bị block ở gateway.
  • Debug khó.

Đây chỉ là distributed monolith chuyển chỗ.

Gateway nên điều phối API, không nên trở thành não nghiệp vụ duy nhất.

Nếu một flow cần orchestration phức tạp, có thể cần:

  • Application service.
  • Workflow service.
  • Saga orchestrator.
  • BFF rõ ràng.

Không nhất thiết là gateway chung.

---

42.29. Gateway và service mesh khác nhau thế nào?

API Gateway thường xử lý north-south traffic:

Client bên ngoài -> hệ thống

Service mesh thường xử lý east-west traffic:

Service -> service bên trong

Gateway:

  • Public API.
  • Auth client.
  • Rate limit external.
  • Route vào hệ thống.

Service mesh:

  • mTLS service-to-service.
  • Retry/timeout nội bộ.
  • Traffic policy giữa service.
  • Observability nội bộ.

Hai thứ có thể cùng tồn tại.

Đừng bắt API Gateway giải quyết mọi service-to-service security nếu service mesh/workload identity phù hợp hơn.

---

42.30. Gateway và WAF khác nhau thế nào?

WAF là Web Application Firewall.

Nó tập trung chặn traffic web nguy hiểm:

  • SQL injection pattern.
  • XSS pattern.
  • Bot/abuse.
  • Rule OWASP.
  • IP reputation.

API Gateway tập trung quản lý API:

  • Routing.
  • Auth.
  • Rate limit.
  • API key.
  • Version.
  • Aggregation.

Một số sản phẩm cloud có cả hai.

Nhưng về tư duy:

WAF bảo vệ khỏi pattern tấn công.
Gateway điều phối và quản lý API.

Chương 44 sẽ nói kỹ hơn về WAF/firewall.

---

42.31. Gateway trong monolith

Monolith cũng có thể dùng API Gateway nếu có nhiều client/public API.

Ví dụ:

Mobile App -> Gateway -> Monolith
Partner API -> Gateway -> Monolith
Admin App -> Gateway -> Monolith

Gateway có thể làm:

  • Rate limit partner.
  • API key.
  • CORS.
  • Request logging.
  • Versioning.

Nhưng nếu chỉ có:

Web frontend -> monolith

thì reverse proxy có thể đủ.

Gateway không chỉ dành cho microservices, nhưng microservices thường làm nhu cầu gateway rõ hơn.

---

42.32. AI Judge: gateway ở giai đoạn nhỏ

AI Judge giai đoạn đầu có thể là:

Frontend
-> Reverse proxy/load balancer
-> Backend monolith/modular monolith
-> DB/Queue/Worker/Object storage

Chưa cần API Gateway riêng.

Backend tự xử lý:

  • Auth.
  • Permission.
  • Route API.
  • Rate limit cơ bản.
  • Job creation.

Điều quan trọng hơn:

  • Worker concurrency.
  • Queue.
  • Idempotency.
  • File storage.
  • Timeout/retry.
  • Monitoring.

Nếu chưa có nhiều service/client, gateway riêng có thể làm chậm tiến độ.

---

42.33. AI Judge: khi gateway bắt đầu hữu ích

Gateway bắt đầu hữu ích khi AI Judge có:

Web app.
Mobile app.
Admin app.
Partner LMS API.
Nhiều backend service.
Public integration API.

Ví dụ route:

/api/auth/*        -> Auth Service
/api/courses/*     -> Course Service
/api/submissions/* -> Submission Service
/api/grading/*     -> Grading Service
/api/billing/*     -> Billing Service
/api/partner/*     -> Partner API/BFF

Gateway có thể:

  • Verify token/API key.
  • Rate limit theo tenant/API key.
  • Route request.
  • Tạo request id.
  • Ghi metrics.
  • Chặn request quá lớn.
  • Chuẩn hóa error format cơ bản.

Nhưng permission như:

Teacher có được chấm submission này không?

vẫn nên ở domain service.

---

42.34. AI Judge: request aggregation cho dashboard

Teacher dashboard có thể cần:

  • Course info.
  • Assignment list.
  • Submission stats.
  • Queue status.
  • Recent grading errors.
  • AI cost summary.

Nếu frontend gọi 6 API, có thể chậm và phức tạp.

Một BFF có thể cung cấp:

GET /teacher/dashboard

Bên trong gọi nhiều service hoặc đọc aggregate.

Nhưng cẩn thận:

Dashboard không nên query live mọi bảng nặng mỗi lần mở.

BFF/gateway aggregation nên dùng:

  • Timeout ngắn.
  • Cache/aggregate nếu phù hợp.
  • Partial response nếu phần phụ lỗi.
  • Permission check rõ.

---

42.35. AI Judge: partner LMS API

Nếu AI Judge tích hợp với LMS của trường, có thể cần API public:

Create assignment.
Sync roster.
Fetch grading result.
Receive webhook.

Gateway hữu ích để:

  • Quản lý API key partner.
  • Rate limit theo trường.
  • Scope API key.
  • Log usage.
  • Route /partner/*.
  • Chuẩn hóa error.
  • Tách public integration khỏi internal API.

Ví dụ:

school_A_lms_key:
  scopes = roster.sync, assignment.write, result.read
  tenant = school_A

Backend vẫn kiểm tra tenant và permission.

Gateway giúp quản lý cửa vào.

---

42.36. AI Judge: không đưa chấm bài lâu vào gateway

Gateway không nên giữ request chấm bài lâu.

Không nên:

POST /grade
Gateway gọi Grading Service
Grading Service gọi AI 90 giây
Gateway chờ
Client chờ

Tốt hơn:

POST /submissions
-> Backend tạo GradingJob
-> Trả job_id/status
-> Worker xử lý
-> Client polling/SSE/WebSocket

Gateway có thể route và rate limit.

Nhưng job dài thuộc queue/worker.

---

42.37. Gateway product nào?

Một số lựa chọn:

  • Nginx/Envoy/HAProxy với config phù hợp.
  • Kong.
  • Tyk.
  • Apigee.
  • AWS API Gateway.
  • AWS ALB + Cognito/Lambda authorizer trong một số setup.
  • Azure API Management.
  • Google API Gateway/Apigee.
  • Cloudflare API Shield/Workers trong một số trường hợp.
  • Traefik.

Không cần chọn tool trước khi hiểu nhu cầu.

Hỏi:

  • Cần API key/developer portal không?
  • Cần auth plugin không?
  • Cần rate limit phân tán không?
  • Cần request aggregation không?
  • Cần self-host hay managed?
  • Team vận hành được gì?
  • Latency/cost thế nào?

Tool theo sau nhu cầu.

---

42.38. Gateway managed hay tự host?

Managed gateway:

Ưu điểm:

  • Đỡ vận hành.
  • Tích hợp cloud.
  • Scale tốt.
  • Có auth/rate limit/logging sẵn.
  • Có SLA tốt hơn nếu cấu hình đúng.

Nhược điểm:

  • Chi phí.
  • Vendor lock-in.
  • Giới hạn tùy biến.
  • Debug có thể phụ thuộc platform.

Self-host gateway:

Ưu điểm:

  • Linh hoạt.
  • Kiểm soát sâu.
  • Có thể rẻ hơn ở một số quy mô.

Nhược điểm:

  • Bạn vận hành HA/scale/upgrade/security.
  • Config sai là bạn chịu.

Thực dụng:

> Nếu team nhỏ và gateway không phải năng lực lõi, managed thường đáng cân nhắc.

---

42.39. Checklist trước khi thêm API Gateway

Hỏi:

  • Hiện có bao nhiêu backend service?
  • Có bao nhiêu loại client?
  • Gateway giải quyết vấn đề cụ thể nào?
  • Vấn đề đó reverse proxy hiện tại có xử lý được không?
  • Auth nào nên ở gateway, auth nào vẫn ở service?
  • Rate limit theo IP/user/tenant/API key?
  • Có cần API key/developer portal không?
  • Có cần aggregation không?
  • Gateway timeout bao nhiêu?
  • Gateway có trở thành single point of failure không?
  • Config gateway deploy/rollback thế nào?
  • Logs/metrics/request id ra sao?
  • Service có bị client bypass gateway không?
  • Gateway có đang ôm business logic quá nhiều không?

Nếu không trả lời rõ, có thể bạn đang thêm gateway vì cảm giác kiến trúc, không phải vì nhu cầu.

---

42.40. Những lỗi phổ biến

Lỗi 1:

Thêm API Gateway khi chỉ có một backend đơn giản.

Lỗi 2:

Gateway verify login rồi service bỏ object-level permission.

Lỗi 3:

Tin header X-User-Id từ gateway nhưng client có thể bypass gateway.

Lỗi 4:

Nhét business logic sâu vào gateway.

Lỗi 5:

Aggregation endpoint gọi quá nhiều service không timeout/fallback.

Lỗi 6:

Rate limit sai key, làm user thật bị chặn hoặc attacker lọt.

Lỗi 7:

Gateway config sai làm toàn bộ API lỗi.

Lỗi 8:

Log token/body nhạy cảm ở gateway.

Lỗi 9:

Gateway timeout nhưng backend vẫn tiếp tục tạo side effect.

Lỗi 10:

Không monitor gateway như một service quan trọng.

---

42.41. Bảng chọn nhanh

| Tình huống | Cách nghĩ thường hợp | |---|---| | Một backend, một web app | Reverse proxy/load balancer thường đủ | | Nhiều service public sau một domain | API Gateway hữu ích | | Nhiều client web/mobile/admin | Cân nhắc BFF | | Partner/public API | Gateway/API management rất hữu ích | | Cần auth/rate limit chung | Gateway có thể xử lý ở cửa vào | | Object-level permission | Service/domain vẫn phải kiểm tra | | Dashboard cần nhiều dữ liệu | BFF/aggregation, nhưng timeout/cache/partial failure rõ | | Job lâu như AI grading | Queue/worker, không giữ request ở gateway | | Gateway bắt đầu chứa nghiệp vụ | Tách sang service/BFF/workflow rõ | | Team nhỏ, nhu cầu đơn giản | Đừng thêm gateway quá sớm |

---

42.42. Tóm tắt bằng AI Judge

Với AI Judge nhỏ:

Frontend
-> Reverse proxy/load balancer
-> Backend modular monolith
-> Queue/worker/database/object storage

có thể đủ.

Gateway riêng bắt đầu đáng cân nhắc khi có:

Nhiều service.
Mobile app.
Admin app.
Partner LMS API.
Public API key.
Rate limit theo tenant/API key.
Dashboard cần aggregation.

Gateway có thể làm:

Route request.
Verify token/API key.
Rate limit.
Tạo request id.
Log/metrics.
Chặn request xấu cơ bản.
Chuẩn hóa public API.

Gateway không nên thay service kiểm tra:

Student có được xem submission này không?
Teacher có được chấm course này không?
Tenant có khớp không?
File này có thuộc user không?

Và gateway không nên chờ chấm bài AI 90 giây.

Việc dài vẫn thuộc queue/worker.

---

42.43. Kết luận của chương

API Gateway là một công cụ mạnh để quản lý cửa vào API.

Nó giúp hệ thống nhiều service/client gọn hơn bằng cách gom các việc như routing, auth chung, rate limit, API key, logging, request id, versioning và đôi khi aggregation.

Nhưng gateway cũng rất dễ bị lạm dụng.

Nếu nhét quá nhiều business logic vào gateway, nó sẽ thành service khổng lồ mới.

Nếu service phía sau bỏ permission vì nghĩ gateway đã lo hết, hệ thống sẽ hở dữ liệu.

Thông điệp cần nhớ:

> Gateway nên làm cửa vào và chính sách API chung. Domain service vẫn phải giữ luật nghiệp vụ và object-level permission.

Ở chương tiếp theo, ta sẽ nói về CDN và edge: CDN giúp static asset, ảnh, video, file download nhanh hơn như thế nào, cache ở edge hoạt động ra sao, signed URL dùng cho protected content thế nào, và khi nào CDN không giúp được gì.