Backend (Logic nghiệp vụ)

Backend là gì?

Backend là phần chạy trên máy chủ, nơi chứa toàn bộ luật nghiệp vụ: ai được làm gì, tính tiền ra sao, khi nào đơn hàng chuyển trạng thái. Người dùng không bao giờ nhìn thấy backend — họ chỉ thấy kết quả của nó.

Điều BA hay bỏ sót: backend không phải một khối duy nhất. Nó gồm nhiều phần, mỗi phần lo một chuyện — đăng nhập, thanh toán, ví điểm thưởng, thông báo. Có hai cách các phần đó được sắp xếp:

Monolith: tất cả nằm trong một codebase, deploy một lần. Đi nhanh khi sản phẩm còn sớm; càng đông người sửa càng vướng nhau.

Microservices: mỗi phần là một service riêng, deploy riêng, nói chuyện với nhau qua API. Mỗi đội tự chủ hơn, nhưng mỗi lần gọi nhau là một chỗ có thể chậm hoặc lỗi.

Hệ quả quan trọng nhất với BA/PO: khi bạn gọi đúng tên phần sở hữu feature, ticket đến đúng đội ngay từ đầu. Và khi một yêu cầu chạm nhiều service, bạn biết rằng rủi ro lớn nhất không nằm trong từng service — mà nằm ở chỗ chúng phối hợp với nhau.

Baseline — bạn hiểu

• Monolith = một backend xử lý tất cả trong một codebase, dễ build sớm, khó scale sau.
• Microservices = tách thành nhiều service nhỏ, mỗi service một trách nhiệm, nói chuyện qua API.
• Backend gồm nhiều phần có tên gọi riêng, không phải "chỗ dev làm việc" chung chung.

Working — bạn làm được

• Nhìn một feature và gọi tên component backend sở hữu nó (auth, ví, nhà cung cấp, thông báo).
• Nhận ra request chạm nhiều service và flag là cross-service flow trong spec.
• Viết ra trạng thái "thành công một phần": bước nào bắt buộc đúng ngay, bước nào được phép trễ, và ai đi dọn khi lệch.

Cơ chế hoạt động

Ví dụ theo cấp độ

Cơ bản — "Đăng nhập chậm" là chậm ở phần nào?

Tình huống: chăm sóc khách hàng chuyển sang một phản ánh: "đăng nhập mất gần 8 giây". Bạn chuẩn bị tạo ticket.

Backend làm những gì khi một người bấm Đăng nhập:

1. Nhận số điện thoại và mật khẩu, kiểm tra mật khẩu có khớp không.
2. Tạo phiên đăng nhập (token) cho thiết bị đó.
3. Đọc hồ sơ người dùng để hiện tên, hạng thành viên, ảnh đại diện.
4. Nếu tài khoản bật xác thực 2 lớp: gọi sang dịch vụ gửi SMS để bắn mã OTP.
5. Ghi lại lịch sử đăng nhập (thiết bị, thời gian) cho mục đích bảo mật.

Một câu hỏi tách được vấn đề: "8 giây đó nằm ở bước kiểm tra mật khẩu, hay ở bước chờ nhà mạng gửi SMS?" Nếu là bước 4 thì đây không phải lỗi code của mình mà là độ trễ của nhà cung cấp SMS — và cách xử lý hoàn toàn khác: đổi nhà cung cấp, hoặc đổi trải nghiệm để người dùng không phải ngồi chờ màn hình trắng.

Học được: backend là nhiều bước nối nhau. Báo bug kèm bước nghi ngờ giúp tiết kiệm hàng ngày điều tra so với báo "đăng nhập chậm".

Trung bình — Một feature chạm hai service

Tình huống: yêu cầu từ marketing: "Khách thanh toán xong thì cộng ngay 1% giá trị đơn vào ví điểm thưởng."

Nó chạm hai service: service thanh toán (biết đơn đã trả tiền hay chưa) và service điểm thưởng (giữ số dư điểm). Không service nào tự làm được cả hai việc.

Dòng cần viết trong ticket:

• "Khi service thanh toán xác nhận đơn ở trạng thái da_thanh_toan, service điểm thưởng cộng 1% giá trị đơn (làm tròn xuống) vào ví điểm của người dùng."
• "Đơn bị hoàn hoặc huỷ sau đó: trừ lại đúng số điểm đã cộng. Nếu người dùng đã tiêu hết điểm, số dư được phép về 0, không xuống âm."
• "Ghi chú: đây là cross-service flow (thanh toán và điểm thưởng) — cần cả hai đội trong buổi refinement."
• "Điểm hiển thị trên màn hình lấy từ service điểm thưởng — đó là nguồn sự thật."

Học được: gọi tên service trong ticket làm lộ ra ngay rằng có hai đội liên quan. Cái giá của việc không gọi tên là một sprint bị lệch vì mỗi đội tưởng bên kia làm.

Nâng cao — Chuỗi ba bước và trạng thái "thành công một phần"

Tình huống: yêu cầu đầy đủ hoá ra là ba bước nối tiếp: (1) thanh toán thành công, (2) cộng điểm vào ví, (3) gửi thông báo "Bạn vừa nhận 4.500 điểm".

Cái bẫy: nhiều BA viết ba bước này như thể chúng luôn cùng thành công hoặc cùng thất bại. Thực tế chúng là ba service khác nhau, và ba kết cục lệch nhau đều xảy ra hằng ngày:

• Bước 1 xong, bước 2 lỗi vì service điểm đang deploy: khách đã trả tiền nhưng không thấy điểm đâu.
• Bước 2 xong, bước 3 lỗi: khách có điểm nhưng không được báo — số dư đổi mà không rõ vì sao.
• Bước 2 được tự động thử lại và chạy hai lần: cộng điểm gấp đôi.

Những dòng phải có trong spec:

• Ưu tiên: tiền phải đúng ngay; điểm được phép trễ tối đa 5 phút; thông báo được phép trễ 15 phút. Không bao giờ vì gửi thông báo lỗi mà huỷ đơn đã thanh toán.
• Chống trùng: mỗi đơn hàng chỉ được cộng điểm đúng một lần, kể cả khi bước cộng điểm bị gọi lại nhiều lần.
• Khi bước 2 thất bại: đưa vào hàng đợi thử lại. Sau 3 lần vẫn lỗi thì đẩy vào báo cáo đối soát hằng ngày để đội vận hành xử lý tay.
• Người dùng thấy gì: trong lúc điểm chưa về, màn hình đơn hàng ghi "Điểm thưởng đang được cộng" thay vì hiện số 0 — vì số 0 làm khách tưởng mình bị mất quyền lợi và gọi lên tổng đài.

Học được: với luồng chạm nhiều service, rủi ro chính không phải code của từng service mà là điều phối giữa chúng. Việc của BA là viết ra trạng thái "thành công một phần" — nếu spec không có nó, sản phẩm vẫn sẽ rơi vào nó, chỉ là không ai đã quyết định trước sẽ xử lý ra sao.

Áp dụng khi viết spec

Với mỗi feature có xử lý phía máy chủ, ticket của bạn phải trả lời được bốn câu:

1. Service nào sở hữu feature này? Service nào giữ dữ liệu gốc?
2. Luồng này chạm mấy service? Nếu từ hai trở lên, đã ghi chú cross-service chưa?
3. Bước nào bắt buộc đúng ngay, bước nào được phép trễ và trễ tối đa bao lâu?
4. Nếu một bước thất bại: có thử lại không, ai phát hiện, người dùng thấy gì trong lúc đó?

Câu hỏi nên hỏi dev

• "Feature này thuộc service nào? Đội nào đang sở hữu service đó?"
• "Request này chạm mấy service từ lúc người dùng bấm tới lúc xong?"
• "Nếu service kia lỗi thì phần còn lại vẫn chạy được chứ, hay hỏng cả luồng?"
• "Bước này gọi trực tiếp hay đẩy vào hàng đợi? Có tự thử lại không?"
• "Nếu bước sau lỗi mà bước trước đã xong thì hệ thống dọn bằng cách nào?"

Sai lầm thường gặp

• Viết "hệ thống tự động cộng điểm" mà không nói service nào làm việc đó.
• Giả định mọi bước trong một luồng cùng thành công hoặc cùng thất bại.
• Bỏ trống trạng thái "thành công một phần" — rồi để vận hành tự xoay khi nó xảy ra.
• Gửi ticket cho nhầm đội và mất vài ngày chỉ để nó được chuyển đúng chỗ.
• Đòi hỏi mọi thứ phải nhất quán tức thì giữa các service, trong khi hệ thống được thiết kế để đồng bộ sau vài giây.

Definition of done — dấu hiệu bạn đã đạt

• Với mỗi feature trong khu vực của mình, bạn gọi được tên service sở hữu nó.
• Mọi ticket chạm nhiều service đều được đánh dấu rõ và có mặt đủ các đội khi refinement.
• Spec của bạn luôn có phần "nếu bước này lỗi thì sao", kèm mốc thời gian trễ chấp nhận được.

Đi sâu hơn

• API (request/response) — đọc tài liệu API và spec phần các service nói chuyện với nhau.