title: "Tính chất của một hệ thống tốt: Scalability, Reliability, Maintainability, và Efficiency"
series: "Software Architecture Masterclass"
part: "Phần 1 — Nguyên lý & Triết lý Kiến trúc"
order: 4
audience: "Solutions Architect & Technical Lead"
reading_time: "13 phút"
tags:

software-architecture
scalability
reliability
maintainability
efficiency
architecture-trade-offs

Tính chất của một hệ thống tốt: Scalability, Reliability, Maintainability, và Efficiency

Có một kiểu dự án mà tôi gặp lặp đi lặp lại: team ngồi lại, vẽ ra kiến trúc "chuẩn" — event-driven, multi-region, auto-scaling, circuit breaker ở mọi tầng, cache nhiều lớp, observability đầy đủ. Sáu tháng sau, sản phẩm vẫn chưa ra được beta, vì đội ngũ 6 người đang phải vận hành một hệ thống được thiết kế cho quy mô 600 người.

Cái sai không nằm ở từng quyết định riêng lẻ. Auto-scaling là ý hay. Circuit breaker là pattern đúng. Multi-layer cache có lý do tồn tại. Cái sai là họ cố gắng tối ưu đồng thời cả bốn tính chất kinh điển của một hệ thống tốt — Scalability, Reliability, Maintainability, Efficiency — như thể bốn thứ này cộng hưởng với nhau một cách miễn phí. Chúng không. Chúng kéo co nhau, và ai không thấy sợi dây đang bị kéo hai đầu thì sẽ build ra một hệ thống mà không tính chất nào thực sự đạt ngưỡng tốt.

Bài này không liệt kê định nghĩa sách giáo khoa của bốn -ility. Nó nói về cái căng thẳng (tension) giữa chúng — thứ quyết định bạn sẽ phải hy sinh cái gì để có được cái gì.

The Problem

Một startup B2B SaaS ở giai đoạn tìm product-market fit, 4 kỹ sư, khoảng 200 khách hàng trả phí. Founder kỹ thuật từng làm ở một công ty scale lớn, mang theo niềm tin: "hệ thống tốt phải scale được, phải reliable, phải dễ maintain, và phải chạy hiệu quả — không có lý do gì để thiếu cái nào."

Kết quả sau 8 tháng: kiến trúc microservices với 11 service cho một sản phẩm mà toàn bộ logic nghiệp vụ có thể viết gọn trong một monolith vừa phải. Mỗi service có retry logic, circuit breaker, riêng một message queue để giao tiếp async "để đảm bảo reliability". Để "đảm bảo scalability", mọi service đều stateless và được thiết kế để chạy trên Kubernetes với horizontal pod autoscaler, dù tải thực tế trung bình chưa tới 50 request/phút.

Cái giá phải trả:

Maintainability sụp đổ: một thay đổi nghiệp vụ đơn giản (thêm field vào invoice) chạm vào 4 service, cần deploy phối hợp, mất 3 ngày thay vì 3 giờ.
Efficiency tệ hại: overhead network call giữa các service, serialize/deserialize JSON liên tục, latency p95 cho một request đơn giản lên tới 800ms — trong khi logic thực tế chỉ mất 20ms nếu chạy trong cùng process.
Reliability không hề tốt hơn: nhiều thành phần hơn đồng nghĩa nhiều điểm hỏng hơn (nguyên lý cơ bản: xác suất hỏng của hệ thống phân tán tăng theo số lượng thành phần phụ thuộc lẫn nhau). Incident xảy ra thường xuyên hơn so với khi còn là monolith, chỉ vì có nhiều thứ hơn để hỏng.
Scalability không ai cần: không có sự kiện scale nào xảy ra trong 8 tháng đó xứng đáng với chi phí đã bỏ ra.

Vấn đề kiến trúc ở đây không phải là "chọn sai pattern". Vấn đề là không ai định nghĩa rõ hệ thống này cần tốt ở cái gì, tại giai đoạn nào — và mặc định rằng theo đuổi cả bốn tính chất cùng lúc là an toàn. Nó không an toàn. Nó là con đường chắc chắn dẫn tới over-engineering.

The Theory

Bốn tính chất (thường gọi là "-ility") là các trục đánh giá chất lượng kiến trúc kinh điển. Định nghĩa ngắn gọn, đủ để dùng làm công cụ tư duy chứ không phải để thuộc lòng:

Scalability — khả năng hệ thống xử lý tải tăng (nhiều người dùng hơn, nhiều dữ liệu hơn, nhiều request hơn) mà không suy giảm hiệu năng đến mức không chấp nhận được, và với chi phí tăng thêm hợp lý (lý tưởng là gần tuyến tính hoặc tốt hơn). Có hai chiều: scale vertical (máy khỏe hơn) và scale horizontal (nhiều máy hơn) — horizontal scaling là thứ mọi người nghĩ tới khi nói "scalable", vì nó gần như vô hạn về lý thuyết.

Reliability — khả năng hệ thống tiếp tục hoạt động đúng chức năng khi có lỗi xảy ra (phần cứng hỏng, network partition, dependency down, bug ở edge case). Đo bằng uptime (99.9%, 99.99%...), MTBF (mean time between failures), MTTR (mean time to recovery). Reliability không phải "không bao giờ lỗi" — đó là ảo tưởng. Nó là "lỗi xảy ra nhưng hệ thống chịu được và phục hồi được".

Maintainability — chi phí (thời gian, rủi ro, effort nhận thức) để hiểu, sửa, mở rộng hệ thống theo thời gian. Đây là tính chất duy nhất trong bốn cái mà lợi ích của nó không xuất hiện ngay lập tức — nó trả cổ tức trong 6 tháng, 2 năm, 5 năm tới, dưới dạng velocity của team không bị suy giảm theo thời gian.

Efficiency — mức độ hệ thống sử dụng tài nguyên (CPU, memory, network, tiền) để tạo ra một đơn vị công việc. Efficiency thấp không có nghĩa hệ thống không chạy được — nó có nghĩa là bạn đang trả nhiều tiền hơn, hoặc chờ lâu hơn, cho cùng một kết quả.

Sách giáo khoa thường trình bày bốn cái này như bốn "phẩm chất mong muốn" độc lập, cứ tối đa hóa hết là được. Thực tế kiến trúc dạy điều ngược lại: chúng nằm trên các trục căng thẳng lẫn nhau, và tại bất kỳ mức đầu tư nguồn lực nào (thời gian, tiền, người), bạn đang phân bổ nguồn lực đó cho một tổ hợp cụ thể của bốn trục — không có tổ hợp nào là "tối đa cả bốn cùng lúc" miễn phí.

Đây chính là lý do vì sao "hệ thống tốt" không phải một khái niệm tuyệt đối — nó là một khái niệm theo ngữ cảnh: tốt cho ai, ở giai đoạn nào, với ràng buộc nguồn lực nào.

The Trade-off

Đây là phần quan trọng nhất — không nói mơ hồ, nói rõ được gì mất gì.

Scalability đánh đổi với Efficiency

Khi bạn thiết kế để scale horizontal (thêm node để xử lý tải), bạn phải trả overhead điều phối: load balancing, service discovery, phân phối state (hoặc bỏ state để chạy stateless — cũng là chi phí thiết kế), network round-trip giữa các node thay vì gọi hàm trong cùng process.

Được: khả năng xử lý tải tăng gần như không giới hạn bằng cách cộng thêm phần cứng, không cần viết lại logic.
Mất: một hệ thống 10 node xử lý cùng một khối lượng công việc mà 1 node mạnh có thể xử lý sẽ luôn kém hiệu quả hơn về tài nguyên tổng — vì một phần tài nguyên đang chi cho việc "nói chuyện giữa các node" thay vì làm việc thực. Chi phí hạ tầng trên mỗi đơn vị công việc tăng, không giảm, khi bạn scale ra theo chiều ngang ở quy mô vừa và nhỏ. Chỉ ở quy mô rất lớn, lợi ích biên của horizontal scaling (linh hoạt, chịu tải đỉnh, không giới hạn phần cứng) mới vượt qua chi phí overhead cố định này.

Nói thẳng: nếu tải của bạn chưa từng chạm giới hạn của một máy chủ tốt, thiết kế cho horizontal scale ngay từ đầu là bạn đang mua trước một khoản efficiency-debt mà chưa chắc bao giờ cần trả bằng lợi ích tương ứng.

Reliability đánh đổi với Efficiency và chi phí

Reliability đến từ redundancy (dự phòng) — nhiều bản sao dữ liệu, nhiều instance của service, failover tự động, retry với backoff, health check liên tục. Mọi cơ chế đó đều tiêu tốn tài nguyên không tạo ra giá trị nghiệp vụ trực tiếp.

Được: hệ thống sống sót qua lỗi phần cứng, network partition, dependency chết tạm thời; giảm downtime, giảm mất dữ liệu.
Mất: chạy 3 replica thay vì 1 nghĩa là trả gấp 3 lần chi phí hạ tầng cho cùng khả năng xử lý logic — 2 trong 3 replica đó, phần lớn thời gian, không làm gì ngoài chờ để thay thế nếu cái đầu tiên chết. Retry logic làm tăng latency trung bình (mỗi lần retry là một round-trip thêm) để đổi lấy latency đuôi (tail latency) tốt hơn khi có lỗi. Đây là đánh đổi kinh điển: bạn trả chi phí thường trực (efficiency thấp hơn mọi lúc) để mua một xác suất thấp về một sự kiện tồi tệ (downtime) không xảy ra.

Câu hỏi kiến trúc thực sự không phải "reliability có tốt không" — luôn tốt về mặt lý thuyết — mà là "downtime 1 giờ có đáng giá bằng chi phí duy trì redundancy suốt 24/7/365 hay không, cho hệ thống cụ thể này". Với một internal tool 20 người dùng, câu trả lời gần như chắc chắn là không.

Maintainability đánh đổi với Scalability (và ngược lại)

Đây là cặp căng thẳng dễ bị bỏ qua nhất, vì cả hai đều được coi là "đức tính tốt" nên trực giác nói chúng phải đi cùng nhau. Không phải vậy.

Một hệ thống dễ maintain thường đơn giản: ít moving parts, ít lớp trừu tượng, logic tập trung, dễ trace một luồng từ đầu đến cuối. Một hệ thống scale tốt thường phức tạp hơn theo cấu trúc: phân tách service theo khả năng scale độc lập, thêm lớp cache, thêm queue để decouple, thêm partition cho dữ liệu.

Được (khi ưu tiên scalability): hệ thống chịu được tải tăng trưởng không tuyến tính mà không cần viết lại kiến trúc.
Mất: mỗi lớp bạn thêm vào để phục vụ khả năng scale trong tương lai (mà có thể không bao giờ đến) là một lớp mà kỹ sư hiện tại phải hiểu, debug, và duy trì ngay hôm nay — kể cả khi tải thực tế chưa cần nó. Đây chính là "premature scaling" — làm phức tạp hệ thống để giải quyết một vấn đề của tương lai giả định, trong khi cái giá về maintainability là có thật và trả ngay lập tức.

Ngược lại, nếu bạn tối ưu maintainability quá mức bằng cách giữ mọi thứ trong một monolith đơn giản, đơn luồng, không phân tách trách nhiệm rõ ràng — thì khi cần scale, bạn sẽ phải trả một hóa đơn tái cấu trúc lớn, dồn vào một thời điểm áp lực cao (thường là khi hệ thống đã đang chịu tải thật).

Không có lựa chọn nào miễn phí. Bạn hoặc trả overhead phức tạp ngay bây giờ (đặt cược tăng trưởng sẽ đến), hoặc trả nợ tái cấu trúc sau này (đặt cược có đủ thời gian và runway để refactor khi cần).

The Architecture Diagram

Sơ đồ dưới thể hiện bốn tính chất như bốn trục của một "radar" — và quan trọng hơn, các đường nối chéo thể hiện lực căng (tension) giữa các cặp, không phải sự hỗ trợ lẫn nhau.

flowchart TD
    subgraph Radar["Bốn trục chất lượng kiến trúc"]
        S["Scalability<br/>(chịu tải tăng)"]
        R["Reliability<br/>(chịu lỗi, phục hồi)"]
        M["Maintainability<br/>(dễ hiểu, dễ sửa)"]
        E["Efficiency<br/>(tối ưu tài nguyên/chi phí)"]
    end

    S -- "overhead điều phối nhiều node<br/>= tốn tài nguyên hơn/đơn vị việc" --> E
    E -- "tối ưu chi phí quá mức<br/>= giới hạn khả năng scale" --> S

    R -- "redundancy, retry, failover<br/>= tốn tài nguyên thường trực" --> E
    E -- "cắt dự phòng để tiết kiệm<br/>= giảm khả năng chịu lỗi" --> R

    M -- "đơn giản hoá, ít lớp trừu tượng<br/>= giới hạn khả năng mở rộng tải" --> S
    S -- "thêm lớp phân tán để scale<br/>= tăng độ phức tạp nhận thức" --> M

    R -- "nhiều thành phần dự phòng hơn<br/>= nhiều điểm có thể hỏng hơn" --> M
    M -- "giữ hệ thống tối giản<br/>= có thể thiếu cơ chế chịu lỗi" --> R

    classDef axis fill:#1e3a5f,stroke:#4a90d9,stroke-width:2px,color:#fff
    class S,R,M,E axis

Đọc sơ đồ này như sau: mỗi mũi tên là một câu "nếu bạn đẩy mạnh đầu này, đầu kia phải trả giá". Không có mũi tên nào đi theo hướng "cả hai cùng tốt lên miễn phí". Đó là bản chất của trade-off kiến trúc — bốn tính chất này không phải bốn thanh trượt độc lập, mà là một hệ ràng buộc lẫn nhau (constraint system).

Implementation Guardrails

Bắt buộc xếp hạng tường minh 2 trên 4 tính chất trước khi thiết kế, không phải sau. Trong tài liệu kiến trúc (ADR — Architecture Decision Record, xem thêm ở bài về documentation), phải ghi rõ: "hệ thống này ưu tiên X và Y, chấp nhận đánh đổi Z và W". Nếu không viết ra được câu này, nghĩa là chưa có quyết định kiến trúc thực sự — chỉ có thói quen hoặc sao chép pattern từ nơi khác.
Ưu tiên phải neo vào giai đoạn kinh doanh cụ thể, có ngày hết hạn. "Ưu tiên Maintainability + Reliability cho tới khi đạt 1000 khách hàng trả phí hoặc 6 tháng nữa, sau đó review lại" — là một guardrail dùng được. "Ưu tiên Maintainability vì nó luôn quan trọng" — không phải guardrail, là khẩu hiệu. Ưu tiên phải gắn với ngưỡng đo được (số user, QPS, SLA hợp đồng), không gắn với cảm tính.
Không đầu tư vào Scalability nếu chưa có bằng chứng đo được về áp lực tải hiện tại hoặc cam kết tăng trưởng cụ thể trong roadmap (hợp đồng đã ký, launch đã lên lịch). "Có thể sau này sẽ cần" không phải bằng chứng — đó là dự đoán. Premature scaling là dạng over-engineering tốn kém nhất vì nó đánh đổi Maintainability (có giá ngay) để mua Scalability (giá trị chưa chắc chắn, ở tương lai không xác định).
Mọi quyết định tăng Reliability (thêm redundancy, retry, failover) phải đi kèm con số SLA mục tiêu cụ thể và được đối chiếu với chi phí vận hành thực tế. Nếu không ai trả lời được câu "downtime bao nhiêu phút/năm là chấp nhận được, và ai là người bị ảnh hưởng khi vượt ngưỡng đó", thì việc thêm cơ chế chịu lỗi chỉ là cảm tính kỹ thuật, không phải quyết định kiến trúc có căn cứ.

Architect's Verdict

Đừng đuổi theo cả bốn tính chất ngang nhau — đó là công thức chắc chắn để build một hệ thống không tốt ở bất kỳ mặt nào, chỉ tốn nguồn lực ở mọi mặt. Một startup giai đoạn đầu, chưa có product-market fit rõ ràng, nên ưu tiên Maintainability + Reliability cơ bản hơn Scalability và Efficiency cực đoan — vì tốc độ thay đổi sản phẩm (pivot, thử nghiệm) quan trọng hơn khả năng chịu tải mà bạn chưa chắc sẽ có, và một hệ thống sập vì bug đơn giản còn tệ hơn một hệ thống chậm vì chưa tối ưu. Khi đã có traction thật (không phải "có thể có"), quay lại re-đánh giá bốn trục này — đó không phải thất bại kiến trúc ban đầu, đó chính là cách kiến trúc tốt vận hành: quyết định phù hợp với ngữ cảnh hiện tại, và sẵn sàng thay đổi khi ngữ cảnh thay đổi.

🔗 Bài viết liên quan: Cấu trúc vs. Hành vi · Cửa sổ thời gian của kiến trúc

Bài trước: Cấu trúc vs. Hành vi · Bài tiếp theo: Cửa sổ thời gian của kiến trúc