Software Architecture: Chia Nhỏ Để Sống Lâu

“Không phải chia nhỏ để tách rời – mà để thở được giữa một thế giới đổi thay quá nhanh.”

🧠 Cuộc họp im re trước bão

Phòng họp Sysops Squad hôm đó im phăng phắc.
Các sếp bước vào, mặt ai cũng căng:

“Cái app ticket của mình đang rối tung, không sửa nổi. Nếu nó sập nữa là phải dẹp luôn bộ phận hỗ trợ khách hàng.”

Addison và Austen – hai kiến trúc sư của đội – chỉ còn biết nhìn nhau.
Addison thở dài:

“Nếu mình không tách cái monolith này ra, nó tự kéo cả đám chết chìm.”

Austen gật đầu:

“Biết vậy, mà sao thuyết phục họ chi thêm tiền được? Lần trước mới than là ngân sách sửa lỗi đã đội lên quá trời.”

Họ nhắn Logan – kiến trúc sư trưởng – nhờ góp ý. Logan hỏi gọn:

“Các cậu chắc tách ra là giải pháp đúng không? Hay chỉ đang đổi một đống rủi ro này lấy rủi ro khác?”

Addison cười méo: “Thật ra tụi em cũng chưa chắc.”
Logan đáp:

“Vậy thì chưa đủ để xin tiền đâu. Muốn thuyết phục được người làm kinh doanh, phải nói được ngôn ngữ của họ: hiệu quả, rủi ro và tốc độ.
Muốn làm được vậy, trước tiên phải hiểu cho rõ modularity đem lại lợi ích gì.”

🌪 Khi thế giới đổi nhanh hơn hệ thống

Doanh nghiệp giờ đổi mặt như chong chóng: sáp nhập, cạnh tranh, AI, DevOps, cloud, CI/CD – thứ gì cũng buộc thay đổi cách ta xây hệ thống.

Kiến trúc phần mềm vốn được xem là “cái khung” khó đổi, nhưng thời buổi này mà cứng quá thì gãy.
Nó phải vừa ổn định, vừa linh hoạt, kiểu như móng nhà biết co giãn khi đất rung.

🥛 Câu chuyện ly nước đầy

Hãy tưởng tượng hệ thống monolith như ly nước.
Ly là server, nước là ứng dụng.
Công ty càng lớn, lượng nước càng nhiều – tới lúc ly đầy, đổ thêm là tràn.
Thêm cái ly khác cũng không giúp gì, vì mỗi ly lại chứa nguyên cái ứng dụng giống nhau.

Giờ, nếu chia nước ra hai ly, ta có thêm chỗ chứa – tương tự như tách app thành hai phần chạy riêng, chia tải và dễ mở rộng hơn.

Architectural modularity đơn giản là vậy: chia nhỏ có chủ đích để mở đường cho thay đổi.

⚙️ Modularity – không phải chuyện kỹ sư thích thì làm

Chia nhỏ hệ thống không phải chuyện “nghe trend microservices rồi làm theo”.
Kiến trúc sư chỉ nên đề xuất khi có lý do rõ ràng, gắn với mục tiêu kinh doanh.

Ba động lực chính:

1. Tốc độ ra sản phẩm mới (Speed-to-market)
2. Lợi thế cạnh tranh (Competitive advantage)
3. Khả năng phản ứng nhanh (Agility)

Đằng sau đó là năm yếu tố kỹ thuật giữ hệ thống sống khỏe:
Maintainability – Testability – Deployability – Scalability – Fault Tolerance.

🔧 Dễ sửa – ít đau đầu hơn (Maintainability)

Monolith giống như mớ dây điện cũ: đụng vô chỗ này là chập chỗ khác.
Chỉ cần thêm một cái “ngày hết hạn” trong wishlist mà phải chỉnh từ giao diện tới database, đụng luôn backend – ba đội làm chung một việc nhỏ.

Trong khi đó, nếu chia nhỏ:

• Với service-based architecture, thay đổi nằm trong đúng domain đó.
• Với microservices, chỉ cần động vào đúng service chịu trách nhiệm.

Chia nhỏ đúng cách giúp làm nhanh, ít rủi ro và đỡ đụng người khác hơn.

🧪 Dễ test – bớt ám ảnh regression

Monolith là cơn ác mộng mỗi lần test: test case nặng, lâu, lỗi tùm lum.
Chia nhỏ làm test nhẹ hơn, chính xác hơn, nhưng chỉ khi các service không bị dính nhau.

Vấn đề không phải “chia nhỏ bao nhiêu”, mà là chia sao cho gọn mà không cột dây vô nhau.

🚀 Dễ deploy – đừng để mỗi lần phát hành là một cuộc cầu nguyện

Deploy monolith giống như thay động cơ giữa lúc máy bay đang bay.
Phải gom cả đống thay đổi vào một đợt phát hành, lỗi một cái là rollback cực.

Khi modular rồi, mỗi service có thể deploy riêng, nhanh và ít rủi ro.
Nhưng nếu phải deploy cả cụm theo thứ tự, thì như Matt Stine nói:

“Nếu microservices của bạn phải triển khai đồng loạt, thôi gom lại thành monolith cho lành.”

📈 Mở rộng và co giãn – hai chuyện khác nhau

Scalability là mở rộng khi lượng người dùng tăng đều.
Elasticity là chịu được “sốc” khi lượng truy cập tăng đột ngột – như bán vé concert.

Modularity giúp đạt cả hai:

• Monolith: mở rộng chậm, khởi động lâu.
• Service-based: đỡ hơn.
• Microservices: nhanh, nhẹ, bật tắt như công tắc.

⚡ Khi hệ thống biết “chịu đau” (Fault Tolerance)

Monolith mà hư là hư cả cụm.
Còn modular, hư đâu thì cô lập chỗ đó, phần còn lại vẫn chạy.

Điều kiện: tránh phụ thuộc đồng bộ (synchronous).
Nếu service A phải đợi B trả lời mới xong, thì A cũng sập theo B.
Giải pháp là dùng asynchronous message hoặc event-driven, để hệ thống tự cân bằng khi một phần lỗi.

💬 Câu chuyện Sysops Squad – và cú “lội ngược dòng”

Sau khi hiểu modularity, Addison và Austen ngồi lại lập business case.
Họ không nói về “microservices” hay “Docker”. Họ nói bằng ngôn ngữ mà ban giám đốc hiểu:

Cuối cùng, họ ghi lại trong ADR – Migrate Sysops Squad Application to a Distributed Architecture.
Không hoa mỹ, chỉ rõ ràng: vì sao làm, làm gì, và hậu quả kèm theo.

🪞 Kết

Modularity không phải liều thuốc tiên.
Nó chỉ đảm bảo hệ thống có thể thay đổi mà không sập.

Không ai chia nhỏ chỉ để “cho đẹp”.
Ta chia nhỏ để thở được – để sửa được, nâng cấp được, và sống lâu trong môi trường đổi liên tục.

“Đôi khi, dũng cảm trong kiến trúc là biết tháo ra đúng lúc để gắn lại cho bền hơn.”