System DesignStrangler fig là tách từng phần, chạy song song, chuyển dần lưu lượng — thay vì viết lại toàn bộ rồi đổi một lần (big bang, rủi ro rất cao và thường không bao giờ về đích vì monolith vẫn tiếp tục thay đổi).
Các bước:
1. Dựng lớp chặn ở biên (reverse proxy / gateway) trước monolith. Ban đầu proxy mọi thứ về monolith — chưa đổi hành vi gì, nhưng đây là chỗ sau này bẻ luồng.
2. Chọn phần tách trước. Ưu tiên phần rìa, ít phụ thuộc, giá trị rõ (thông báo, tìm kiếm, xuất báo cáo) hoặc phần cần scale riêng. Đừng bắt đầu bằng lõi thanh toán.
3. Tách dữ liệu trước khi tách code. Ngừng mọi truy cập chéo bảng: monolith chỉ được chạm dữ liệu đó qua một interface trong code. Đây là bước tốn thời gian nhất và cũng là bước hay bị bỏ qua.
4. Viết service mới, ghi song song. Chạy giai đoạn ghi cả hai nơi và đối chiếu (so kết quả cũ/mới trên lưu lượng thật, chỉ đọc từ bên cũ) để tự tin về tính đúng.
5. Chuyển lưu lượng dần ở lớp chặn: 1% → 10% → 100%, có công tắc quay lui tức thì.
6. Xoá code cũ. Bước này bắt buộc — không xoá thì kết quả là hai bản triển khai cùng tồn tại, chi phí bảo trì tăng chứ không giảm.
Bẫy hay gặp:
- Chia sẻ database kéo dài. Nếu service mới vẫn đọc thẳng bảng của monolith thì chưa tách được gì, chỉ chuyển code sang chỗ khác.
- Foreign key và transaction xuyên ranh giới. Sau khi tách, JOIN và transaction chung biến mất — phải thay bằng API composition hoặc saga.
- Giai đoạn quá độ kéo dài vô hạn. Song song hai hệ thống là trạng thái tốn kém; cần mốc thời gian và người chịu trách nhiệm đóng lại.
- Đóng băng monolith. Không thể yêu cầu ngừng phát triển tính năng trong lúc tách — quá trình phải sống chung với thay đổi liên tục.