Chapter 8: Factor VIII — Concurrency

Scale theo process model, không dồn mọi thứ vào một “siêu instance”

  • Theo Twelve-Factor, khi cần scale, ứng dụng nên scale out qua process model: chia các loại công việc thành các process type khác nhau như web, worker, clock, rồi tăng giảm số lượng process cho từng loại một cách độc lập. Tài liệu gốc gọi toàn bộ ma trận “loại process + số lượng của từng loại” là process formation.
  • Twelve-Factor thừa nhận một process có thể tự dùng threads hoặc async/event loop, nhưng nhấn mạnh rằng một VM hoặc một process đơn lẻ chỉ lớn đến một mức nào đó; vì vậy hệ thống vẫn phải có khả năng trải ra nhiều process trên nhiều máy.
  • Twelve-Factor cũng yêu cầu app không tự daemonize, không tự ghi PID files; thay vào đó hãy để process manager của hệ điều hành hoặc cloud platform chịu trách nhiệm quản lý output streams, restart khi crash, và xử lý restart/shutdown do người dùng yêu cầu.
  • Trong thực tế hiện đại, Heroku cho phép scale độc lập các process type như web=2 worker=4 clock=1, còn Kubernetes hỗ trợ horizontal scaling bằng cách tăng số Pod replicas hoặc dùng HorizontalPodAutoscaler để tự động điều chỉnh năng lực theo tải.

1) Mở bài: vì sao factor này rất dễ “đụng trần” trong dự án thật?

Khi ứng dụng còn nhỏ, nhiều team thường nghĩ theo kiểu rất tự nhiên: “cứ tăng RAM và CPU cho con server hiện tại là được.” Cách đó đôi khi giúp được một thời gian, nhưng đến lúc hệ thống phải xử lý nhiều loại tải khác nhau như HTTP request, background jobs, scheduled jobs, email, thumbnail generation, queue consumers, thì một “cục app khổng lồ” bắt đầu trở nên khó scale, khó tối ưu chi phí, và khó kiểm soát độ trễ. Factor VIII của Twelve-Factor xuất hiện đúng ở điểm đó: hãy scale qua process model.

2) Định nghĩa gốc của Factor VIII

Tên chính thức của factor này là:

“Concurrency — Scale out via the process model.”

Tài liệu gốc nói rất rõ rằng trong Twelve-Factor app, process là công dân hạng nhất. Nhà phát triển nên thiết kế ứng dụng để xử lý các loại workload khác nhau bằng cách gán từng loại việc cho một process type riêng. Ví dụ mà tài liệu gốc nêu trực tiếp là: HTTP requests do một web process xử lý, còn các tác vụ nền chạy lâu do một worker process xử lý.

Nói theo cách thật dễ hiểu cho junior:

Thay vì cố bắt một instance làm mọi việc, bạn nên tách các loại công việc thành các nhóm process có vai trò riêng, rồi scale đúng nhóm đang nghẽn.

3) “Process model” nghĩa là gì?

Process model là cách bạn nhìn ứng dụng như một tập các loại process có trách nhiệm rõ ràng. Tài liệu Twelve-Factor nói mô hình này lấy cảm hứng mạnh từ Unix process model cho các service daemons. Mỗi loại process làm một kiểu việc tương đối rõ, thay vì gom tất cả vào một tiến trình hỗn hợp.

Heroku diễn giải rất dễ hiểu: một process type là “prototype” để từ đó sinh ra một hay nhiều dyno, giống như một class sinh ra nhiều object. Các process type khác nhau đại diện cho workload diversity, còn số lượng dyno trong mỗi cột đại diện cho scale.

4) Vì sao Twelve-Factor không chỉ dựa vào threads hay async?

Tài liệu gốc không phủ nhận threads hoặc async/evented model. Nó nói rất rõ rằng một process vẫn có thể dùng internal multiplexing như threads trong VM hoặc event loop kiểu Node.js. Nhưng đồng thời, tài liệu cũng nhấn mạnh: một VM chỉ grow đến một mức nào đó, nên ứng dụng vẫn cần có khả năng trải ra nhiều process chạy trên nhiều máy vật lý.

Đây là một điểm rất quan trọng: Factor VIII không bảo bạn “đừng dùng async” hay “đừng dùng multithreading”. Nó nói rằng những kỹ thuật đó không thay thế cho khả năng scale ở cấp process. Nói cách khác, tối ưu trong một process là tốt, nhưng không nên biến nó thành cái cớ để bỏ qua khả năng horizontal scaling.

5) Vertical scaling và horizontal scaling khác nhau thế nào?

Tài liệu gốc của Twelve-Factor nói thẳng rằng một VM hay một process đơn lẻ chỉ có thể lớn thêm đến một giới hạn, và vì thế app cần có khả năng chạy trên nhiều process, nhiều máy. Đó chính là lý do của horizontal scaling.

Kubernetes diễn giải điều này bằng ngôn ngữ rất hiện đại: horizontal scaling là phản ứng với tải tăng bằng cách triển khai nhiều Pod hơn, còn vertical scaling là tăng thêm tài nguyên như CPU hoặc memory cho các Pod hiện có. HorizontalPodAutoscaler tự động cập nhật số lượng replicas của một workload như Deployment hoặc StatefulSet để đáp ứng nhu cầu.

Nói gần gũi hơn:

  • Vertical scaling là “cho nhân viên hiện tại làm trên bàn to hơn”.
  • Horizontal scaling là “thuê thêm người làm cùng loại việc”.
    Factor VIII nghiêng rất mạnh về tư duy thứ hai.

6) “Process formation” là gì?

Một trong những câu rất đáng nhớ của tài liệu gốc là: mảng các process type và số lượng process của từng loại được gọi là process formation. Ví dụ, bạn có thể có 2 web, 4 worker, 1 clock.

Heroku dùng đúng mô hình này trong tài liệu process model và scaling. Ví dụ của họ cho thấy bạn có thể scale bằng lệnh kiểu heroku ps:scale web=2 worker=4 clock=1, trong đó:

  • web là traffic HTTP,
  • worker là xử lý background jobs,
  • clock là scheduling.

Điểm hay của process formation là nó buộc bạn nghĩ về ứng dụng theo vai trò vận hành, chứ không chỉ theo code modules. Đây là một bước trưởng thành rất rõ khi chuyển từ “viết app” sang “vận hành app”.

7) Ví dụ đời thường cực dễ hiểu

Hãy tưởng tượng bạn vận hành một nhà hàng.

  • web process giống như nhân viên nhận order ở quầy.
  • worker process giống như đội bếp làm món.
  • clock process giống như người phụ trách nhắc các việc định kỳ như kiểm kho, đóng sổ, gửi báo cáo.

Nếu khách đông, bạn không nhất thiết phải tuyển thêm người kiểm kho. Bạn cần tuyển thêm người nhận order hoặc thêm đầu bếp, tùy điểm nghẽn nằm ở đâu. Đó chính là tư duy scale theo process model: mỗi loại việc có process type riêng, và mỗi loại được scale độc lập. Ý này bám sát định nghĩa process types và formation trong Twelve-Factor và Heroku docs.

8) Ví dụ xuyên suốt với ứng dụng mẫu TaskFlow

Ta tiếp tục dùng ứng dụng mẫu TaskFlow, một SaaS quản lý công việc cho đội nhóm.

TaskFlow có thể có ít nhất 3 process type:

  • web: nhận HTTP requests từ người dùng.
  • worker: xử lý gửi email, tạo báo cáo, đồng bộ dữ liệu nền.
  • clock: kích hoạt job định kỳ, ví dụ quét task quá hạn hoặc gửi summary hằng ngày. Cách tách web và worker như vậy khớp với ví dụ gốc của Twelve-Factor và tài liệu process model của Heroku.

Cách làm đúng

Khi TaskFlow bị chậm ở phần gửi email hoặc sinh báo cáo PDF, team tăng số lượng worker mà không đụng vào web. Khi traffic người dùng tăng mạnh, team tăng web mà không cần scale bừa tất cả. Đây chính là lợi ích của process formation: scale đúng loại việc đang nghẽn.

Cách làm sai

App chỉ có một tiến trình “làm tất cả”: vừa nhận HTTP requests, vừa render báo cáo nặng, vừa gửi email, vừa polling queue, vừa chạy lịch định kỳ. Kết quả là chỉ cần background jobs tăng đột biến, web requests cũng bị chậm theo. Heroku docs về background workers nói rõ worker riêng giúp tránh việc web dynos bị chiếm dụng, giữ site responsive hơn và cho phép monitor/control/scale worker độc lập.

9) Một ý rất quan trọng: process không nên tự daemonize

Twelve-Factor nói rất rõ: app processes không nên daemonize và không nên ghi PID files. Thay vào đó, hãy dựa vào process manager của hệ điều hành, cloud platform, hoặc công cụ dành cho development để:

  • quản lý output streams,
  • phản ứng với crashed processes,
  • xử lý restart và shutdown.

Điều này nghe hơi “sysadmin”, nhưng lại rất thực chiến. Nếu app tự fork, tự chạy nền, tự ghi PID files, bạn đang làm mờ ranh giới trách nhiệm giữa app và platform. Twelve-Factor muốn ranh giới đó rõ ràng: app là process, còn process manager mới là thứ quản process.

10) Case thực tế đã được xác minh

Heroku: process types và dynos

Heroku mô tả rất rõ mối quan hệ giữa process types và dynos:

  • process type là “prototype”,
  • dynos là các instance thực thi của process type đó,
  • scale được thực hiện bằng cách tăng số dynos cho từng process type.

Heroku còn có tài liệu riêng cho background jobs, nêu rằng worker processes có thể được monitor, control và scale độc lập với web dynos; điều này giúp web requests không bị long-running work làm chậm.

Kubernetes: scale replicas và autoscaling

Kubernetes docs nói scaling được thực hiện bằng cách thay đổi số replicas của một Deployment. Khi scale out, Kubernetes tạo thêm Pods mới để đạt desired state. HorizontalPodAutoscaler còn có thể tự động điều chỉnh số replicas của Deployment hoặc StatefulSet theo metrics như CPU, memory hoặc custom metrics.

Hai ví dụ này rất khác nhau về platform, nhưng lại cùng phản ánh một ý gốc của Factor VIII: đừng nghĩ scale chỉ là “cho máy mạnh hơn”; hãy nghĩ tới việc thêm process/replicas cho đúng loại workload.

11) Junior thường hiểu sai ở đâu?

Hiểu sai 1: “Concurrency ở đây chỉ là thread hay async”

Không đúng. Twelve-Factor đang nói về concurrency ở mức process model. Tài liệu gốc thừa nhận threads/async có ích, nhưng vẫn nhấn mạnh rằng app phải có thể span multiple processes running on multiple physical machines.

Hiểu sai 2: “Scale là tăng CPU/RAM cho một instance”

Đó chỉ là vertical scaling. Factor VIII tập trung vào scale out qua process model. Kubernetes docs cũng phân biệt rất rõ horizontal scaling với vertical scaling.

Hiểu sai 3: “Web chậm thì cứ tăng tất cả”

Không hợp lý. Khi dùng process formation, bạn có thể tăng worker mà không tăng web, hoặc ngược lại. Heroku docs còn cho ví dụ rõ ràng về việc scale web và worker độc lập.

Hiểu sai 4: “App tự fork ra chạy nền là chuyên nghiệp hơn”

Theo Twelve-Factor, ngược lại mới đúng: app processes không nên tự daemonize hay tự ghi PID files; việc đó thuộc về process manager.

12) Làm sai thì hậu quả gì?

  • Khó scale đúng chỗ nghẽn, vì mọi loại công việc bị dồn vào một process type duy nhất.
  • Web traffic bị background jobs làm chậm, vì long-running work tranh tài nguyên với request/response path. Heroku docs nói riêng về lợi ích của worker riêng để tránh điều này.
  • Lãng phí tài nguyên, vì muốn scale một loại việc lại phải scale cả cục app. Điều này trái hẳn tinh thần workload diversity của process types.
  • Vận hành rối hơn, vì app tự ôm luôn trách nhiệm daemonizing, restart logic và PID management thay vì để platform lo phần đó.

13) Áp dụng đúng trong team như thế nào?

Bước 1: Vẽ lại ứng dụng theo loại công việc

Hãy tự hỏi:

  • cái gì là HTTP request path,
  • cái gì là background processing,
  • cái gì là scheduling,
  • cái gì là one-off admin task.

Twelve-Factor và Heroku đều diễn giải ứng dụng bằng chính các process type kiểu này.

Bước 2: Mỗi loại việc thành một process type rõ ràng

Ví dụ:

  • web
  • worker
  • clock
  • queue-high
  • queue-low

Heroku docs còn gợi ý rằng một số app có hai loại worker riêng cho urgent jobs và long-running jobs, để có khả năng phản hồi tốt hơn cho urgent work và kiểm soát compute granular hơn.

Bước 3: Scale theo bottleneck thật

Nếu queue backlog tăng mà latency web vẫn ổn, hãy scale worker, không phải cả hệ thống. Nếu traffic web tăng nhưng background jobs vẫn nhẹ, hãy scale web. Đây chính là lợi ích lớn nhất của process formation.

Bước 4: Để platform làm việc của platform

Đừng để app tự daemonize hay cố làm process supervisor. Hãy để systemd, cloud process manager, Heroku dyno manager, hoặc controller của Kubernetes lo việc giám sát và restart.

Bước 5: Chuẩn bị cho autoscaling nếu cần

Kubernetes HPA có thể tự scale workload như Deployment theo metrics; Heroku cũng có autoscaling cho web dynos trên một số tier. Đây là lớp mở rộng hiện đại rất hợp với tinh thần Factor VIII, miễn là app đã được mô hình hóa thành process types hoặc scalable workloads rõ ràng.

14) Diễn giải trong bối cảnh hiện đại

Blog chính thức năm 2025 của Twelve-Factor nói rằng các nguyên lý cốt lõi vẫn hữu ích cho platform builders hiện đại trong bối cảnh cloud-native, nơi service composition, process management và scaling ngày càng phức tạp. Nhìn theo ngôn ngữ hiện đại, Factor VIII có thể được hiểu là: thiết kế ứng dụng để platform có thể tăng giảm năng lực xử lý theo từng loại workload, thay vì coi app như một khối nguyên không chia được.

Cần phân biệt rõ:

  • Nguyên lý gốc: scale out via the process model.
  • Diễn giải hiện đại: dynos, replicas, HPA, autoscaling, queue-specific workers, và declarative workload management là những cách ngày nay hiện thực hóa nguyên lý đó.

15) Checklist tự đánh giá

Hãy tự hỏi về ứng dụng của bạn:

  • Tôi có xác định rõ các process type khác nhau trong app chưa?
  • Tôi có thể scale web và worker độc lập không?
  • Khi queue backlog tăng, tôi có cách tăng worker mà không ảnh hưởng web không?
  • App có đang tự daemonize hoặc dựa vào PID files không?
  • Nếu đang chạy trên Kubernetes, workload của tôi có đang được mô hình hóa sao cho replicas/HPA có thể phát huy tác dụng không?

Nếu bạn thấy mình trả lời “chưa rõ” cho vài câu ở trên, Factor VIII của hệ thống đó đang còn yếu.

16) Tóm tắt nhanh

  • Twelve-Factor xem process là first-class citizen.
  • Scale đúng tinh thần Twelve-Factor là scale out qua process model, không chỉ phóng to một instance.
  • Các loại việc khác nhau nên có process type khác nhau như web, worker, clock.
  • Số lượng của từng process type tạo thành process formation.
  • App không nên tự daemonize; việc quản lý vòng đời process nên để process manager hoặc cloud platform đảm nhiệm.

17) Nguồn tham khảo