Khoa NguyenTech Lead
Khoa Nguyen
Sẵn sàng cho vị trí Senior Tech Lead

Khoa
Nguyen

Tinh hoa kỹ thuật cấp ngân hàng, tốc độ của người sáng lập.

“Tôi không xây cho lý thuyết. Tôi xây cho ngày khách hàng gọi và CEO đã hứa xong.”

Đặt cuộc gọi 30 phútTải CV
Hiện tại
Trưởng nhóm kỹ thuật One-ID · làm việc tại trụ sở TPBank
Quy mô
2 ngân hàng tier-1 · ~10M người dùng · ~5M giao dịch/ngày
Thâm niên
5 năm vận hành · không một lỗi kiểm toán
Địa điểm
Hà Nội · GMT+7 · sẵn sàng làm việc từ xa
Cuộn xuống xem hệ thống & quyết định
§01 · Tóm tắt điều hành

Ba con số
quyết định.

  1. 01Doanh thu

    Chủ sở hữu kỹ thuật của nền tảng mang lại ~3,3 triệu USD doanh thu/năm cho One-ID, phục vụ hai ngân hàng hàng đầu Việt Nam trong 5 năm liên tục.

  2. 02Hiệu suất & chi phí

    Chuyển dịch sang hạ tầng tự vận hành giúp giảm P99 từ ~300ms xuống ~45ms và chi phí hạ tầng ~60% [ước tính], đồng thời duy trì ~5M giao dịch/ngày.

  3. 03Tuân thủ

    Không một lỗi kiểm toán. Không một cam kết khách hàng bị lỡ. Đồng hành cùng đội chín kỹ sư, đồng thời đảm nhận vai trò Tech Lead, PM, PO, BA và Scrum Master.

§02 · Sản phẩm

5 năm vận hành
bên trong ứng dụng ngân hàng.

Hai nền tảng gánh trọng lượng của portfolio này. Cả hai chạy trong môi trường thật, đối diện đội an ninh ngân hàng thật, phục vụ lưu lượng người dùng thật.

01 · Vận hành · 5 năm

Loyalty & Privilege Banking Platform

Tích hợp trong ứng dụng TPBank Mobile Banking · phục vụ BIDV Private Banking · ~10M người dùng · ~5M giao dịch/ngày · không một lỗi kiểm toán trong 5 năm.

  • Thương mại voucher, đặt phòng chờ sân bay và giao quà vật lý cùng vận hành trên một nền tảng — toàn bộ vòng đời từ phát hành đến đối soát hàng tháng.
  • Tích hợp tầng Premier Banking mà không đánh đổi việc che dữ liệu CIF ở mức phiên làm việc.
  • 5 năm vận hành liên tục, vượt qua mọi vòng kiểm toán của bộ phận an ninh TPBank.

Công nghệ — Bun + Elysia · Postgres mỗi service · Kafka · Kubernetes · Istio mTLS

02 · Đang triển khai · 2026 →Tái xây dựng chiến lược

ONE-CORE Migration

Tái xây dựng khối monolith Laravel thành nền tảng microservices đa khách hàng cấp tài chính.

  • Độ trễ P99 giảm từ ~300ms xuống ~45ms trên các endpoint đã chuyển [ước tính].
  • Cắt ~60% chi phí hạ tầng so với dịch vụ đám mây trước đây [ước tính].
  • Ranh giới kiểm toán theo từng service — vùng ảnh hưởng sự cố và phạm vi kiểm toán đều được cô lập.
  • Lộ trình 2027: mở rộng từ 2 ngân hàng tier-1 hiện tại thành nền tảng SaaS đa ngân hàng tại Việt Nam.
Aside · vì sao 5 năm một công ty

5 năm liên tục chạm tay vào production banking là depth proof không mua được bằng interview. Khi rời, tôi mang theo framework vận hành đã được battle-test 5 năm — không phải lý thuyết.

Bên lề · sản phẩm khác đã vận hành

Cũng đã đưa vào vận hành: ứng dụng tài xế Flutter cấp đội xe (GPS hai băng tần, ưu tiên ngoại tuyến, xác thực sinh trắc học) và Vietnam Tileserver — hệ vector tile tự vận hành, loại bỏ phụ thuộc Google Maps / Mapbox cho mọi luồng dữ liệu địa lý.

§03 · Hệ thống

Tư duy hệ thống phân tán
— không chắp vá.

Phần dưới không phải danh sách công cụ — đây là tập nhỏ những quyết định đã định hình cách nền tảng thực sự mở rộng, gặp lỗi và phục hồi.

§03.1 — Chuyển dịch, nhìn song song

Dẫn dắt bằng ADR · đang triển khai
Trước · 2021
Monolith dạng module
  • Monolith Laravel dạng module
  • MySQL dùng chung
  • Gọi đồng bộ kiểu yêu cầu/phản hồi
  • Triển khai thủ công
  • Thời gian chạy do nhà cung cấp quản lý
Chuyển dịchDẫn dắt bằng ADR
Sau · 2026 →
Microservices · hướng sự kiện
  • Microservices · Bun + Elysia
  • Postgres · mỗi service một cơ sở dữ liệu
  • Kafka hướng sự kiện (Outbox · Saga)
  • ArgoCD GitOps · phát hành tự động
  • Kubernetes tự vận hành + Istio mTLS

§03.2 — Năm quyết định công nghệ chiến lược

Lựa chọn · thay vì · lý do · kết quả
  1. 01

    Tự vận hành Bun + Elysia

    thay vì AWS Lambda + API Gateway

    Lý do
    Thời gian khởi động không chấp nhận được với luồng ngân hàng có SLA; chi phí Lambda tăng phi tuyến theo lưu lượng sự kiện loyalty.
    Kết quả
    P99 ~300ms → ~45ms; chi phí thời gian chạy giảm ~60% [ước tính].
  2. 02

    Mỗi service một cơ sở dữ liệu trên PostgreSQL

    thay vì MySQL dùng chung kế thừa từ monolith Laravel

    Lý do
    Tách ranh giới kiểm toán theo service — một bảng bị xâm phạm không lan ra; mỗi service có thể được kiểm toán độc lập khi ngân hàng yêu cầu.
    Kết quả
    Phạm vi kiểm toán thu hẹp từ "toàn bộ cơ sở dữ liệu" xuống một service mỗi lần; vùng ảnh hưởng sự cố được cô lập ngay từ thiết kế.
  3. 03

    Tự vận hành Kubernetes + Istio

    thay vì Dịch vụ đám mây quản lý (EKS / GKE)

    Lý do
    Yêu cầu chủ quyền dữ liệu từ khách hàng ngân hàng Việt Nam, kết hợp tối ưu chi phí ở quy mô 5M giao dịch/ngày.
    Kết quả
    Chủ quyền dữ liệu đáp ứng yêu cầu an ninh TPBank; mTLS giữa các service không phụ thuộc chi phí egress của nhà cung cấp.
  4. 04

    Kiến trúc hướng sự kiện Kafka (Outbox + Saga)

    thay vì Gọi RPC đồng bộ giữa các service

    Lý do
    Luồng loyalty và ngân hàng có nhiều bước và có thể hoàn tác. Gọi đồng bộ tạo lỗi lan truyền và xóa dấu vết kiểm toán.
    Kết quả
    Hệ thống vẫn nhận yêu cầu ghi khi một service phía dưới gặp sự cố; nhật ký sự kiện trở thành dấu vết kiểm toán chỉ ghi thêm trong bảy năm.
  5. 05

    Pipeline AI review đa tác tử trong CI

    thay vì Duyệt mã thuần con người

    Lý do
    Đội chín kỹ sư không đủ năng suất duyệt cấp ngân hàng nếu chỉ dùng con người; lỗi cơ học phải được bắt trước khi tốn thời gian của người duyệt.
    Kết quả
    Mỗi pull request đi qua bốn AI reviewer (Kiến trúc · Bảo mật · Hiệu năng · Quy chuẩn) trước hai vòng duyệt của người. Chạy dưới gói thuê bao cố định, có ngưỡng chi tiêu cứng mỗi ngày và mô hình dự phòng — chi phí không bùng nổ khi lưu lượng PR tăng đột biến.

§03.3 — AI trong vận hành thực tế

Chi phí có hạn · kiểm soát qua CI

Mỗi pull request đi qua bốn AI reviewer — Kiến trúc, Bảo mật, Hiệu năng, Quy chuẩn — trước hai vòng duyệt của người, kiểm soát trong CI dưới ngân sách thuê bao cố định với ngưỡng chi tiêu cứng mỗi ngày.

AI không thay người duyệt — nó loại bỏ nhóm lỗi cơ học trước khi người duyệt phải động vào thay đổi.

§04 · Lãnh đạo

Dẫn dắt qua hệ thống
— không qua khẩu hiệu.

§04.1 — Triết lý vận hành

Phần lớn những gì tôi đưa ra thị trường trong 5 năm qua chưa tồn tại trước cuộc họp với khách. Khách muốn ra mắt trong một đến hai tuần; phạm vi đúng chuẩn phải mất nhiều tháng. CEO đã hứa. Tôi là người giữ lời hứa đó.

Mô hình giữ ổn định 5 năm gồm ba bước:

  1. 1

    Lắng nghe — cắt phạm vi một cách trung thực. Tách phần khách thật sự cần để trình bày với cấp trên của họ ra khỏi phần còn lại.

  2. 2

    Triển khai — không bao giờ đánh đổi bảo mật. Che dữ liệu CIF, ký HMAC và nhật ký kiểm toán luôn nằm trong V1. Không bao giờ chuyển sang V2.

  3. 3

    Củng cố — tinh chỉnh sau khi đã ra mắt an toàn. Sau đó chuẩn hóa qua ADR khi nhịp vận hành đã ổn định.

Kết quả 5 năm: không một cam kết khách hàng bị lỡ, không một phát hiện kiểm toán. Tốc độ là một quyết định kỹ thuật, không phải lời xin lỗi.

§04.2 — Cách tôi vận hành như CTO

01

Quyết định bằng RFC trước tiên

Mọi quyết định lớn — nhà cung cấp, lược đồ dữ liệu, kiến trúc service mới — đều cần một RFC tối đa hai trang trước khi viết dòng code đầu tiên. RFC được duyệt bất đồng bộ; không họp nếu một tài liệu có thể giải quyết. Khi hợp nhất, RFC trở thành ADR.

02

Nhịp tuần cố định

Thứ Hai: lên kế hoạch và ưu tiên (tối đa 45 phút). Giữa tuần: tập trung làm việc sâu, không họp trừ khi có sự cố. Thứ Sáu: duyệt demo, retrospective, và một vòng xem chỉ số — năng suất PR, thời gian dẫn, số lượng sự cố.

03

Tuyển vì tinh thần làm chủ

Tôi tuyển dựa trên: khả năng viết rõ ràng, lịch sử đã giao sản phẩm dưới ràng buộc thật và sự thoải mái khi nói "không" với việc phình phạm vi. Công nghệ học được trong sáu tuần; tinh thần làm chủ thì không.

§04.3 — Bài học lớn nhất

Vận hành đội chín kỹ sư ở quy mô ngân hàng dạy tôi rằng hệ thống thắng anh hùng — và những anh hùng từ chối được thay thế bằng hệ thống là người đầu tiên cần được đưa ra khỏi đội.

§04.4 — Đội ngũ & hệ thống đã xây dựng

Đã xây · duy trì · tài liệu hóa
  1. 01
    Khung phân cấp chức danh

    L3 / L4 / Manager · tiêu chí thăng tiến đo lường được · kỳ vọng định nghĩa rõ theo từng cấp.

  2. 02
    Ma trận trách nhiệm RACI

    Mọi service đều có người phụ trách xác định. Không có service vô chủ, luồng leo thang sự cố rõ ràng.

  3. 03
    Trực sự cố kèm runbook bắt buộc

    Một runbook cho mỗi loại sự cố. Senior dự phòng cho mid-level. Báo cáo sau sự cố là bắt buộc.

  4. 04
    Lộ trình đào tạo nội bộ

    Junior đạt mức làm việc độc lập trong 6–9 tháng — kèm cặp, duyệt mã, nhận trách nhiệm theo từng bước.

  5. 05
    Tech Lead kiêm vai trò liền kề

    Tech Lead là chuyên môn chính. Khi đội còn dưới 10 kỹ sư, tôi kiêm PM/PO/BA/Scrum Master để giữ tinh gọn — không tự nhận chuyên gia ở các vai trò đó, sẵn sàng giao lại khi có chuyên trách.

§05 · Liên hệ

Sẵn sàng cho vị trí
Senior Tech Lead.

Đặt cuộc gọi 30 phútkhoait109@gmail.com
Email
khoait109@gmail.com
Calendly
calendly.com/kaynvn
LinkedIn
linkedin.com/in/kayn403
Địa điểm
Hà Nội · GMT+7
© 2026 Khoa Nguyen