Mở đầu — vì sao bài này quan trọng
Ở Bài 42, chúng ta đã đi qua bức tranh tổng quan về các pattern tích hợp: từ point-to-point, ESB, cho đến API Gateway. Bạn đã biết API Gateway là gì ở mức khái niệm — một "cổng" đứng trước hệ thống backend. Nhưng khi bước vào một dự án thật, bạn sẽ ngồi họp với đội kỹ thuật và nghe những cái tên rất cụ thể: "team mình dùng Kong", "phía đối tác triển khai trên AWS API Gateway", hoặc "khách hàng enterprise yêu cầu Apigee". Lúc đó, nếu bạn chỉ biết khái niệm chung chung mà không hình dung được mỗi nền tảng làm được gì, có điểm mạnh điểm yếu ra sao, bạn sẽ khó tham gia vào quyết định kiến trúc và khó viết được spec yêu cầu cho đúng.
Là một BA, bạn không cần biết cách code một plugin cho Kong hay cấu hình IAM policy cho AWS. Nhưng bạn cần hiểu API Gateway gánh những trách nhiệm gì, để khi viết yêu cầu nghiệp vụ, bạn biết tính năng nào nên đẩy xuống Gateway lo, tính năng nào thuộc về service. Bạn cũng cần đủ vốn từ để đọc được tài liệu kỹ thuật, đặt câu hỏi đúng với đội dev, và ước lượng được tác động chi phí lẫn rủi ro khi chọn một nền tảng. Bài này sẽ đi sâu vào những trách nhiệm cốt lõi của một API Gateway và soi chiếu chúng qua ba "ông lớn" mà bạn chắc chắn sẽ gặp: Kong, AWS API Gateway và Apigee.
Khái niệm cốt lõi
API Gateway thực chất làm gì
Hãy hình dung backend của một công ty fintech Việt Nam có hàng chục service nhỏ: service xác thực người dùng, service ví điện tử, service lịch sử giao dịch, service thông báo. Nếu mỗi ứng dụng client (app mobile, web, đối tác) phải tự biết địa chỉ từng service, tự xử lý đăng nhập, tự đối phó với việc service đổi địa chỉ — thì hệ thống sẽ rối loạn. API Gateway giải quyết bằng cách đứng ở giữa: client chỉ nói chuyện với Gateway, Gateway lo phần còn lại. Cụ thể, một Gateway hiện đại đảm nhận các nhóm trách nhiệm sau.
1. Routing — định tuyến yêu cầu đến đúng backend
Đây là chức năng nền tảng nhất. Gateway nhận một request và quyết định gửi nó tới service nào, dựa trên path (đường dẫn), host, header, hoặc thậm chí method. Ví dụ: mọi request tới /api/wallet/ được chuyển tới service ví, còn /api/auth/ đi tới service xác thực. Nhờ đó client chỉ cần một địa chỉ duy nhất (api.cong-ty.vn), còn việc tách nhỏ service phía sau hoàn toàn vô hình với họ. Khi đội dev tách một service lớn thành hai service nhỏ, client không cần sửa gì — chỉ cần Gateway cập nhật route.
2. Authentication và Authorization — kiểm tra danh tính và quyền
Thay vì mỗi service tự viết lại logic kiểm tra token, Gateway làm việc này một lần ở "cửa". Nó validate Bearer token (JWT), kiểm tra API Key, hoặc xác thực OAuth trước khi cho request đi tiếp. Service phía sau có thể tin tưởng rằng mọi request đã qua Gateway đều đã được xác thực. Đây là nguyên tắc "xác thực tập trung" — giảm trùng lặp và giảm rủi ro một service nào đó quên kiểm tra quyền.
3. Rate limiting — giới hạn tần suất gọi
Gateway đếm số request từ mỗi client (theo API Key, theo IP, theo user) và chặn nếu vượt ngưỡng, ví dụ "tối đa 1000 request/phút". Điều này bảo vệ backend khỏi bị quá tải, chống lạm dụng, và là cơ sở để bán các gói dịch vụ khác nhau (gói free 100 request/ngày, gói trả phí 100.000 request/ngày).
4. Caching — lưu tạm phản hồi
Với những dữ liệu ít thay đổi (ví dụ danh mục sản phẩm, tỷ giá cập nhật mỗi 5 phút), Gateway có thể lưu lại phản hồi và trả về ngay cho request giống hệt tiếp theo mà không cần làm phiền backend. Kết quả: phản hồi nhanh hơn và backend nhẹ tải hơn.
5. Transformation và Aggregation — biến đổi và gộp dữ liệu
Gateway có thể chỉnh sửa request/response trên đường đi: thêm/bớt header, đổi định dạng, hoặc gộp kết quả từ nhiều service thành một phản hồi duy nhất cho client. Điều này đặc biệt hữu ích khi backend là legacy nhưng client cần một định dạng mới.
6. Observability — quan sát và đo lường
Vì mọi request đều đi qua Gateway, đây là điểm lý tưởng để ghi log, đo lưu lượng, đo độ trễ, đếm lỗi. Gateway cung cấp dashboard cho biết "API nào được gọi nhiều nhất", "tỷ lệ lỗi 5xx hôm nay", "client nào tiêu thụ tài nguyên nhiều nhất".
Ba nền tảng phổ biến — so sánh để chọn đúng
Kong là một Gateway mã nguồn mở (open source), bạn tự cài đặt và vận hành trên hạ tầng của mình (self-hosted), dù cũng có bản trả phí Kong Konnect dạng cloud. Điểm mạnh của Kong là hiệu năng cao và hệ thống plugin phong phú — gần như mọi tính năng (rate limit, JWT, logging, CORS...) đều là một plugin bật/tắt được. Kong phù hợp với doanh nghiệp muốn kiểm soát toàn quyền, không bị khóa vào một nhà cung cấp cloud nào (tránh "vendor lock-in"), và có đội DevOps đủ năng lực vận hành.
AWS API Gateway là dịch vụ managed (do AWS quản lý hạ tầng) trong hệ sinh thái Amazon. Điểm mạnh là tích hợp cực mượt với các dịch vụ AWS khác, đặc biệt là Lambda (serverless). Bạn không phải lo cài đặt, vá lỗi, scale máy chủ — AWS lo hết. Mô hình tính tiền theo lượng request thực tế (pay-per-use). Phù hợp với team đã ở trong hệ sinh thái AWS và muốn triển khai nhanh. Đổi lại, bạn bị ràng buộc vào AWS, và một số tính năng nâng cao về quản trị API thì kém phong phú hơn Apigee.
Apigee (thuộc Google Cloud) định vị ở phân khúc enterprise — không chỉ là Gateway kỹ thuật mà là một nền tảng "API Management" đầy đủ: cổng dành cho lập trình viên (developer portal), phân tích kinh doanh (analytics), tính tiền theo lượng dùng (monetization), quản lý vòng đời API. Apigee mạnh khi công ty xem API là một sản phẩm để bán hoặc mở cho hàng trăm đối tác bên ngoài. Đổi lại, chi phí cao và độ phức tạp lớn hơn nhiều.
Một cách dễ nhớ: Kong là "linh hoạt, tự chủ"; AWS là "nhanh gọn, hợp với serverless và hệ sinh thái Amazon"; Apigee là "đồ sộ, hợp khi API là sản phẩm bán cho bên ngoài".
Tình huống thực tế
Ví dụ 1: Sàn thương mại điện tử chọn Kong để tránh vendor lock-in
Một sàn TMĐT giả định tên Chợ Việt có khoảng 25 microservice và lượng truy cập đỉnh dịp sale lên tới 40.000 request/giây. Ban đầu họ định dùng AWS API Gateway vì hạ tầng đang ở AWS, nhưng đội kiến trúc lo ngại hai điều: chi phí AWS API Gateway tính theo từng triệu request sẽ phình to ở các đợt flash sale, và họ muốn giữ khả năng chuyển sang nhà cung cấp cloud khác trong tương lai để đàm phán giá.
Họ chọn Kong tự host trên cụm máy chủ trong Kubernetes. BA của dự án — chính là vai trò bạn đang học — đã viết yêu cầu rất cụ thể trong spec: "Gateway phải áp rate limit 200 request/phút cho gói khách thường, 2000 request/phút cho gói khách VIP, phân biệt qua API Key"; "phản hồi của API danh mục sản phẩm được cache 60 giây". Đội dev hiện thực bằng cách bật plugin rate-limiting và proxy-cache của Kong, gắn theo từng nhóm consumer. Kết quả mùa sale, backend service danh mục giảm 70% lượng truy vấn nhờ cache, và không service nào bị sập vì quá tải.
Bài học rút ra: quyết định chọn Gateway không chỉ là chuyện kỹ thuật mà gắn chặt với chiến lược chi phí và rủi ro vendor lock-in. BA cần đưa các con số (ngưỡng rate limit, thời gian cache) vào spec dưới dạng yêu cầu rõ ràng, chứ không nói chung chung "cần giới hạn truy cập".
Ví dụ 2: Startup fintech dùng AWS API Gateway để ra mắt nhanh
Một startup fintech ở TP.HCM, gọi là PayNhanh, có đội kỹ thuật chỉ 6 người và cần ra mắt MVP trong 3 tháng. Họ chọn kiến trúc serverless: mỗi tính năng là một hàm Lambda, đứng trước là AWS API Gateway. Lý do là họ không có DevOps riêng để vận hành Kong, và AWS API Gateway tích hợp Lambda gần như chỉ bằng vài cú click — định tuyến /payment, /refund, /balance tới ba Lambda tương ứng.
Gateway tự lo việc validate JWT phát hành bởi AWS Cognito (dịch vụ xác thực của AWS), tự bật throttling mặc định để chống tấn công, tự ghi log sang CloudWatch. BA trong dự án này tập trung viết yêu cầu về error response: khi token hết hạn thì trả 401 với thông điệp tiếng Việt thân thiện; khi vượt rate limit thì trả 429. Nhờ tận dụng tính năng có sẵn của Gateway, đội dev không phải tự code lớp xác thực, kịp ra mắt đúng hạn.
Bài học rút ra: với team nhỏ, ưu tiên hàng đầu là tốc độ và ít gánh nặng vận hành. AWS API Gateway "managed" giúp đội tập trung vào nghiệp vụ thay vì hạ tầng. BA cần nhận ra: rất nhiều yêu cầu phi chức năng (xác thực, throttle, log) có thể được đáp ứng bởi cấu hình Gateway thay vì code mới — điều này tiết kiệm thời gian và cần được ghi nhận đúng trong spec.
Ví dụ 3: Ngân hàng dùng Apigee để mở Open Banking cho đối tác
Một ngân hàng lớn tại Việt Nam triển khai Open Banking — mở API cho các công ty fintech đối tác tích hợp (chuyển khoản, truy vấn số dư qua sự đồng ý của khách). Đây không còn là bài toán "cổng kỹ thuật" đơn thuần, mà là "API như một sản phẩm": cần cổng đăng ký cho đối tác tự lấy API Key, cần báo cáo lượng dùng để đối soát và tính phí, cần quản lý nhiều phiên bản API song song, cần kiểm soát quyền chi tiết theo từng đối tác.
Họ chọn Apigee. Đối tác tự đăng ký qua developer portal, nhận credentials, đọc tài liệu API ngay tại đó. Apigee thống kê mỗi đối tác gọi bao nhiêu request, lỗi bao nhiêu, từ đó bộ phận kinh doanh xuất hóa đơn theo gói. BA ở dự án này làm việc nhiều với cả đội kỹ thuật lẫn đội kinh doanh: định nghĩa các gói (tier) — "gói cơ bản 10.000 lượt/tháng miễn phí, vượt thì 50đ/lượt" — và mô tả luồng onboarding đối tác.
Bài học rút ra: khi API trở thành sản phẩm bán cho bên ngoài, bạn cần một nền tảng API Management đầy đủ chứ không chỉ một Gateway routing. Apigee tỏa sáng ở đây nhờ developer portal, analytics và monetization. BA phải hiểu các khái niệm tier, quota, developer portal để bắc cầu giữa nhu cầu kinh doanh và năng lực kỹ thuật.
Hướng dẫn từng bước
Khi bạn là BA tham gia một dự án có API Gateway, đây là quy trình làm việc gợi ý:
- Liệt kê các trách nhiệm cần đặt ở Gateway. Rà soát từng nhóm: routing, auth, rate limit, caching, transformation, observability. Với mỗi nhóm, hỏi: nghiệp vụ có cần không? Nếu có thì yêu cầu cụ thể là gì? Ví dụ rate limit: ngưỡng bao nhiêu, phân biệt theo gói khách thế nào.
- Phân định ranh giới Gateway và service. Làm rõ tính năng nào do Gateway lo (xác thực token, throttle) và tính năng nào do service lo (logic nghiệp vụ, kiểm tra quyền chi tiết theo dữ liệu). Tránh để cùng một logic bị làm hai lần, hoặc tệ hơn là không ai làm.
- Đối chiếu với nền tảng đang dùng. Nếu team dùng Kong, hỏi xem có plugin sẵn cho yêu cầu của bạn không. Nếu dùng AWS, kiểm tra tính năng built-in. Nếu dùng Apigee, tận dụng developer portal và analytics. Điều này giúp bạn biết yêu cầu nào "miễn phí" (chỉ cần cấu hình) và yêu cầu nào cần code mới (tốn effort).
- Viết yêu cầu phi chức năng kèm con số. "Cache 60 giây", "rate limit 200 req/phút theo API Key", "trả 429 khi vượt ngưỡng". Con số cụ thể giúp dev cấu hình chính xác và giúp QA kiểm thử được.
- Định nghĩa hành vi lỗi và phản hồi. Khi token sai, khi vượt giới hạn, khi backend sập — Gateway trả status code nào, thông điệp ra sao. Đây thường bị bỏ sót nhưng ảnh hưởng trực tiếp đến trải nghiệm client.
- Xác định nhu cầu observability. Cần dashboard nào, cảnh báo khi nào (ví dụ tỷ lệ lỗi 5xx vượt 1% thì báo động). Gateway là nơi lý tưởng để lấy các số liệu này.
Lỗi thường gặp & mẹo
Nhầm API Gateway với Load Balancer. Hai thứ này hay bị lẫn. Load balancer (Bài 37) chủ yếu phân tải đều giữa các bản sao của cùng một service ở tầng mạng. API Gateway hoạt động ở tầng ứng dụng, hiểu được nội dung request (path, header, token) và làm các việc thông minh như xác thực, rate limit, biến đổi dữ liệu. Một hệ thống thường có cả hai.
Dồn quá nhiều logic nghiệp vụ vào Gateway. Gateway nên lo các mối quan tâm chung (cross-cutting concerns): xác thực, throttle, log. Nếu bạn nhét logic tính giá, tính khuyến mãi vào Gateway, nó sẽ phình to, khó bảo trì và trở thành điểm nghẽn. Mẹo: logic nghiệp vụ ở lại service, Gateway chỉ làm "người gác cổng và điều phối".
Bỏ quên chi phí vận hành khi so sánh nền tảng. Kong "miễn phí" về license nhưng tốn người và máy để vận hành. AWS/Apigee đắt về phí dịch vụ nhưng rẻ về nhân lực vận hành. Khi tư vấn chọn nền tảng, đừng chỉ nhìn giá license — hãy nhìn tổng chi phí sở hữu (TCO) gồm cả nhân sự DevOps.
Quên rằng Gateway cũng là một single point of failure. Vì mọi request đi qua Gateway, nếu nó sập thì toàn hệ thống ngừng. Mẹo: trong yêu cầu phi chức năng, nhớ đề cập tính sẵn sàng cao (high availability) và phương án dự phòng cho chính Gateway.
Mẹo về vốn từ khi đọc tài liệu. Khi gặp "plugin" (Kong), "stage/usage plan" (AWS), "proxy/product/quota" (Apigee), hãy ánh xạ chúng về sáu trách nhiệm cốt lõi ở trên. Tên gọi khác nhau nhưng bản chất xoay quanh routing, auth, rate limit, caching, transformation, observability.
Bài tập thực hành
- Lập bảng so sánh. Tạo bảng ba cột Kong / AWS API Gateway / Apigee, các hàng là: mô hình triển khai (self-host hay managed), điểm mạnh nổi bật, đối tượng phù hợp, rủi ro vendor lock-in. Tự điền dựa trên bài học.
- Viết yêu cầu Gateway cho một tình huống. Giả sử bạn làm BA cho một app đặt đồ ăn. Hãy viết 5 yêu cầu phi chức năng liên quan đến Gateway, mỗi yêu cầu kèm con số cụ thể (ví dụ rate limit cho API tìm quán, cache cho API menu, status code khi vượt giới hạn).
- Phân định ranh giới. Với app đặt đồ ăn ở trên, liệt kê 3 tính năng nên đặt ở Gateway và 3 tính năng nên ở service, giải thích vì sao.
- Tình huống chọn nền tảng. Một công ty logistics có đội DevOps mạnh, muốn tránh phụ thuộc một cloud, lưu lượng rất lớn. Bạn khuyên dùng nền tảng nào trong ba cái trên? Viết 3 câu lập luận.
Tóm tắt
API Gateway là cổng đứng trước backend, gánh sáu nhóm trách nhiệm cốt lõi: routing (định tuyến theo path/header), authentication (xác thực tập trung), rate limiting (giới hạn tần suất), caching (lưu tạm phản hồi), transformation/aggregation (biến đổi và gộp dữ liệu) và observability (log, đo lường). Ba nền tảng phổ biến mang ba triết lý khác nhau: Kong linh hoạt và tự chủ, hợp với team muốn kiểm soát và tránh vendor lock-in; AWS API Gateway nhanh gọn dạng managed, hợp với serverless và hệ sinh thái AWS; Apigee đồ sộ ở phân khúc enterprise, hợp khi API là một sản phẩm bán cho đối tác bên ngoài.
Với vai trò BA, bạn không cần cấu hình Gateway, nhưng bạn cần biết đẩy yêu cầu nào xuống Gateway, viết yêu cầu phi chức năng kèm con số cụ thể, phân định ranh giới Gateway và service, đối chiếu với năng lực nền tảng để ước lượng effort, và đừng quên các rủi ro như single point of failure hay tổng chi phí sở hữu. Nắm vững những điều này, bạn sẽ tự tin ngồi cùng đội kiến trúc và đóng góp vào những quyết định quan trọng nhất của hệ thống.