Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được nhận vào vị trí Technical Product Manager tại một công ty fintech ở TP.HCM. Trong buổi đầu tiên, kiến trúc sư trưởng (tech lead) vẽ lên bảng một sơ đồ chằng chịt: vài ô hình chữ nhật nối với nhau bằng mũi tên, có chữ "load balancer", "API gateway", "Redis", "Postgres read replica", "Kafka", "S3"... Anh ấy quay sang hỏi bạn: "Theo em, nếu mình thêm tính năng này thì nên đặt logic ở service nào?". Cả phòng nhìn bạn. Nếu lúc đó bạn không hiểu sơ đồ trước mặt, bạn sẽ mất uy tín ngay trong tuần đầu — không phải vì bạn dở, mà vì bạn chưa có "bản đồ" để định vị mình trong cuộc trò chuyện kỹ thuật.
Đây chính là lý do Bài 5 tồn tại. Một Technical PM không cần code mỗi ngày, nhưng bắt buộc phải đọc được sơ đồ kiến trúc, gọi đúng tên các thành phần trong hệ thống, và hiểu mỗi lớp (layer) của tech stack giải quyết vấn đề gì. Khi bạn nắm được "bức tranh tổng thể" này, bạn sẽ ước lượng được độ phức tạp của một tính năng, đặt câu hỏi đúng chỗ trong cuộc họp, và quan trọng nhất: trao đổi với kỹ sư bằng cùng một ngôn ngữ.
Bài học này là tấm bản đồ tổng quan. Các bài sau sẽ đào sâu từng vùng trên bản đồ đó — client-server (Bài 6), REST API (Bài 7), database scaling (Bài 50), caching (Bài 48)... Còn ở đây, mục tiêu của chúng ta là giúp bạn nhìn toàn cảnh và biết "cái gì nằm ở đâu".
Khái niệm cốt lõi
Tech stack là gì?
"Tech stack" (ngăn xếp công nghệ) là tập hợp tất cả công nghệ — ngôn ngữ lập trình, framework, cơ sở dữ liệu, hạ tầng — mà một sản phẩm phần mềm sử dụng để chạy. Gọi là "stack" (ngăn xếp) vì các thành phần này xếp chồng lên nhau theo lớp: lớp dưới phục vụ lớp trên. Người dùng nhìn thấy lớp trên cùng (giao diện), còn phần lớn công sức kỹ thuật nằm ở các lớp bên dưới mà họ không bao giờ thấy.
Cách dễ nhất để PM ghi nhớ là chia stack thành 4 lớp lớn: Frontend (giao diện) → Backend (xử lý logic) → Data (lưu trữ) → Infrastructure (hạ tầng vận hành). Ta sẽ đi qua từng lớp.
Lớp 1 — Frontend (phần người dùng nhìn thấy)
Đây là lớp client — chạy trên trình duyệt hoặc điện thoại của người dùng. Frontend chịu trách nhiệm hiển thị giao diện và bắt thao tác (bấm nút, nhập liệu). Một số tên bạn sẽ nghe thường xuyên:
- Web: React, Vue, Angular là ba framework phổ biến nhất. React (do Meta tạo ra) chiếm thị phần lớn nhất ở Việt Nam. Next.js là framework dựa trên React, hỗ trợ render phía server để load nhanh và tốt cho SEO.
- Mobile: Có hai hướng. Native (Swift cho iOS, Kotlin cho Android) cho hiệu năng tốt nhất nhưng phải viết hai lần. Cross-platform (Flutter của Google, React Native của Meta) viết một lần chạy cả hai nền tảng — nhiều startup Việt chọn hướng này để tiết kiệm chi phí đội ngũ.
Lớp 2 — Backend (bộ não xử lý logic)
Backend là phần chạy trên máy chủ, xử lý nghiệp vụ: kiểm tra mật khẩu, tính tiền đơn hàng, gọi cổng thanh toán, ghi dữ liệu. Người dùng không thấy backend, nhưng đây là nơi chứa hầu hết "trí tuệ" của sản phẩm. Các ngôn ngữ và framework backend phổ biến:
- Node.js (JavaScript): nhẹ, nhanh khi triển khai, hợp với startup và real-time. Rất phổ biến ở Việt Nam.
- Java/Kotlin (Spring Boot): "xương sống" của ngân hàng, fintech, hệ thống lớn cần ổn định.
- Python (Django, FastAPI): mạnh cho data và AI/ML.
- Go, PHP (Laravel), C# (.NET), Ruby on Rails: mỗi cái có chỗ đứng riêng.
Lớp 3 — Data (nơi lưu trữ)
Dữ liệu phải nằm ở đâu đó. Lớp này gồm:
- Cơ sở dữ liệu quan hệ (SQL): PostgreSQL, MySQL. Dữ liệu có cấu trúc bảng rõ ràng, đảm bảo tính nhất quán. Phù hợp dữ liệu giao dịch (đơn hàng, tài khoản, thanh toán).
- Cơ sở dữ liệu phi quan hệ (NoSQL): MongoDB, DynamoDB. Linh hoạt hơn về cấu trúc, mở rộng dễ. Hợp với dữ liệu thay đổi nhiều hoặc khối lượng cực lớn.
- Cache: Redis, Memcached. Bộ nhớ đệm tốc độ cao, giữ dữ liệu hay truy cập để khỏi phải hỏi database mỗi lần.
- Lưu trữ tệp: Amazon S3, Google Cloud Storage — chứa ảnh, video, file PDF.
Lớp 4 — Infrastructure (hạ tầng vận hành)
Lớp này trả lời câu hỏi: "Code chạy ở đâu và bằng cách nào?".
- Cloud: AWS, Google Cloud, Microsoft Azure. Đa số sản phẩm hiện đại chạy trên cloud thay vì tự mua máy chủ.
- Container & điều phối: Docker (đóng gói ứng dụng), Kubernetes (quản lý hàng loạt container).
- CI/CD: GitHub Actions, GitLab CI — tự động kiểm thử và đưa code lên môi trường thật.
- CDN: Cloudflare — đẩy nội dung đến gần người dùng để load nhanh hơn.
Cách đọc một sơ đồ kiến trúc
Khi nhìn sơ đồ, hãy lần theo đường đi của một request: người dùng bấm nút → request đi từ frontend → qua API gateway / load balancer → đến backend service → backend hỏi database hoặc cache → trả kết quả ngược lại. Nếu bạn lần được dòng chảy này, bạn đã đọc được 80% sơ đồ. Mũi tên là hướng dữ liệu đi; mỗi ô là một thành phần. Đừng sợ những cái tên lạ — hãy hỏi "ô này nằm ở lớp nào trong 4 lớp?".
Tình huống thực tế
Tình huống 1 — Tiki và bài toán mở rộng ngày sale 11/11
Một sàn thương mại điện tử lớn như Tiki vào ngày sale 11/11 phải chịu lượng truy cập gấp 20–30 lần ngày thường. Giả sử ban đầu hệ thống chỉ có một database PostgreSQL phục vụ mọi truy vấn. Trong ngày sale, hàng trăm nghìn người cùng mở trang sản phẩm — database quá tải, trang load chậm 8–10 giây, nhiều người bỏ giỏ hàng.
Đội kỹ thuật xử lý bằng cách thêm lớp cache Redis: thông tin sản phẩm (giá, ảnh, mô tả) ít thay đổi nên được giữ trong Redis, request đọc lấy từ cache thay vì hỏi database mỗi lần. Kết quả: thời gian load giảm còn dưới 1 giây, database "thở" được vì 90% lượt đọc đã được cache hấp thụ.
Bài học cho PM: Khi bạn nghe đội kỹ thuật nói "cần thêm caching layer", đó không phải vẽ vời. Hiểu lớp data giúp bạn biết vì sao một tính năng "chỉ là hiển thị giá" lại có thể sập hệ thống vào giờ cao điểm — và vì sao việc đầu tư hạ tầng đôi khi quan trọng ngang việc làm tính năng mới.
Tình huống 2 — Startup giao đồ ăn chọn Flutter để tiết kiệm 6 tháng
Một startup giao đồ ăn ở Hà Nội, đội ngũ chỉ 8 kỹ sư, cần ra mắt app cho cả iOS và Android trong 4 tháng để kịp gọi vốn vòng seed. PM đứng trước hai lựa chọn frontend mobile:
- Native: chất lượng cao nhất, nhưng cần đội iOS riêng và đội Android riêng — với 8 người là bất khả thi, và sẽ mất khoảng 8 tháng.
- Flutter (cross-platform): một codebase chạy cả hai nền tảng, đội nhỏ vẫn kham được, ước tính 4 tháng.
Bài học cho PM: Lựa chọn tech stack là quyết định kinh doanh có vỏ bọc kỹ thuật. PM phải tham gia vào quyết định này bằng cách đặt lên bàn cân: thời gian ra thị trường, ngân sách đội ngũ, chất lượng trải nghiệm. Bạn không chọn công nghệ, nhưng bạn định khung trade-off để cùng tech lead chọn.
Tình huống 3 — Fintech và lý do không thể "đổi sang NoSQL cho nhanh"
Tại một công ty ví điện tử (tương tự MoMo hay ZaloPay), một PM mới đề xuất chuyển toàn bộ database số dư tài khoản từ PostgreSQL sang MongoDB vì nghe nói "NoSQL mở rộng dễ hơn". Tech lead phản đối ngay.
Lý do: dữ liệu số dư đòi hỏi tính nhất quán giao dịch tuyệt đối — khi A chuyển 100.000đ cho B, hai thao tác trừ tiền và cộng tiền phải xảy ra trọn vẹn cùng nhau, không được phép một nửa. Đây gọi là tính chất ACID, và SQL được thiết kế cho việc này. Nếu để xảy ra sai lệch, tiền của người dùng có thể "bốc hơi" — một thảm họa với fintech.
Bài học cho PM: Đừng vội đề xuất đổi công nghệ vì một từ khóa nghe hấp dẫn. Mỗi lựa chọn ở lớp data có lý do tồn tại. Hiểu trade-off giữa SQL và NoSQL giúp bạn tránh đề xuất ngây thơ làm mất uy tín, và biết khi nào nên đặt câu hỏi "tính nhất quán dữ liệu ở đây có quan trọng không?".
Hướng dẫn từng bước
Đây là quy trình để bạn "giải mã" tech stack của chính sản phẩm mình đang quản lý:
- Xin sơ đồ kiến trúc hiện tại. Hỏi tech lead: "Mình có architecture diagram nào không? Em muốn hiểu hệ thống tổng quan." Đây là câu hỏi hoàn toàn hợp lý của một Technical PM.
- Phân loại từng thành phần vào 4 lớp. Cầm sơ đồ, dán nhãn mỗi ô: nó thuộc Frontend, Backend, Data, hay Infrastructure? Việc này biến mớ tên lạ thành một cấu trúc bạn nắm được.
- Lần theo đường đi của một request quen thuộc. Chọn một thao tác bạn biết rõ — ví dụ "người dùng đăng nhập" — và hỏi: request đi qua những ô nào, theo thứ tự nào? Khi bạn kể lại được hành trình đó, bạn đã thực sự hiểu sơ đồ.
- Lập một bảng "stack hiện tại" của riêng bạn. Ghi ra: frontend dùng gì, backend ngôn ngữ gì, database loại nào, chạy trên cloud nào. Đây là tài liệu tham chiếu cá nhân, cập nhật khi có thay đổi.
- Với mỗi thành phần, hỏi một câu "vì sao". "Vì sao mình chọn React mà không phải Vue?" "Vì sao có Redis ở đây?" Câu trả lời sẽ tiết lộ những trade-off và ràng buộc lịch sử — đây là vàng khi bạn lên kế hoạch tính năng.
- Nối stack với lộ trình sản phẩm. Khi đánh giá một tính năng mới, tự hỏi: nó chạm vào lớp nào? Nếu chạm cả 4 lớp, độ phức tạp cao hơn nhiều so với tính năng chỉ đổi giao diện.
Lỗi thường gặp & mẹo
Lỗi 1 — Giả vờ hiểu để khỏi mất mặt. Đây là cái bẫy lớn nhất. Khi nghe một thuật ngữ lạ trong họp, gật gù cho qua sẽ khiến bạn càng ngày càng lạc lối. Mẹo: hỏi thẳng "Cho mình hỏi nhanh, Kafka ở đây đóng vai trò gì?". Kỹ sư tôn trọng PM ham học hỏi hơn nhiều so với PM giả vờ biết.
Lỗi 2 — Nhầm "công nghệ mới" với "công nghệ tốt hơn". Công nghệ thời thượng không tự động phù hợp với bài toán của bạn. Mẹo: luôn hỏi "nó giải quyết vấn đề gì mà cái hiện tại không làm được?". Nếu không có câu trả lời rõ ràng, đừng đổi.
Lỗi 3 — Bỏ quên lớp Infrastructure khi tính chi phí. PM hay chỉ nghĩ đến công sức code mà quên rằng mỗi service mới còn kéo theo chi phí cloud, giám sát, vận hành. Mẹo: khi ước lượng tính năng lớn, hỏi thêm "cái này phát sinh chi phí hạ tầng gì không?".
Lỗi 4 — Đề xuất giải pháp kỹ thuật thay vì mô tả vấn đề. Đừng nói "mình nên dùng microservices". Hãy nói "tính năng A đang bị nghẽn vì phụ thuộc tính năng B, có cách nào tách ra không?". Để kỹ sư chọn công cụ; bạn nêu vấn đề và ràng buộc.
Mẹo vàng: Dành 30 phút mỗi tuần đọc một thuật ngữ kỹ thuật bạn gặp nhưng chưa hiểu. Sau 3 tháng, vốn từ kỹ thuật của bạn sẽ đủ để theo kịp mọi cuộc thảo luận quan trọng.
Bài tập thực hành
- Vẽ lại stack sản phẩm của bạn. Lấy sản phẩm bạn đang làm (hoặc một app bạn dùng hàng ngày như Grab, Shopee). Vẽ sơ đồ 4 lớp và điền tên công nghệ vào từng lớp theo hiểu biết của bạn. Sau đó nhờ một kỹ sư kiểm tra giúp — bạn sai chỗ nào là chỗ đó bạn học được nhiều nhất.
- Lần theo một request. Chọn thao tác "thêm sản phẩm vào giỏ hàng" trên một app thương mại điện tử. Viết ra hành trình của request qua các lớp, từ lúc bấm nút đến lúc thấy giỏ hàng cập nhật. Đánh dấu chỗ nào bạn không chắc.
- Phân tích một trade-off. Viết một đoạn ngắn (150 từ) trả lời: "Nếu sản phẩm của tôi cần lưu nhật ký hoạt động người dùng với khối lượng cực lớn nhưng không cần nhất quán tuyệt đối, tôi nên chọn SQL hay NoSQL? Vì sao?". Dùng lý lẽ từ bài học.
- Lập danh sách câu hỏi. Viết ra 5 câu hỏi về tech stack mà bạn muốn hỏi tech lead trong buổi 1-1 tới. Mục tiêu: mỗi câu hỏi giúp bạn hiểu sâu hơn một lớp trong stack.
Tóm tắt
Technical PM không cần viết code, nhưng cần một tấm bản đồ để định vị mình trong mọi cuộc trò chuyện kỹ thuật. Tấm bản đồ đó là tech stack, chia thành 4 lớp dễ nhớ: Frontend (giao diện người dùng thấy), Backend (bộ não xử lý logic), Data (nơi lưu trữ), và Infrastructure (hạ tầng vận hành). Cách đọc một sơ đồ kiến trúc đơn giản là lần theo đường đi của một request qua các lớp.
Quan trọng nhất, lựa chọn công nghệ luôn là một trade-off — như startup chọn Flutter để ra mắt nhanh, hay fintech giữ SQL để đảm bảo tiền không sai lệch. Vai trò của bạn không phải chọn công nghệ, mà là đặt lên bàn cân những ràng buộc kinh doanh (thời gian, chi phí, chất lượng, rủi ro) để cùng tech lead ra quyết định đúng. Hãy mạnh dạn hỏi khi không hiểu, đừng giả vờ biết, và mỗi tuần học thêm một chút. Các bài tiếp theo sẽ đưa bạn đi sâu vào từng vùng trên bản đồ này — bắt đầu từ Bài 6 với mô hình client-server và giao thức HTTP.