Microservices vs Monolith không phải câu hỏi về "cái nào tốt hơn" — nhà tuyển dụng dùng nó để kiểm tra bạn có tư duy đánh đổi (trade-off) hay chỉ học thuộc buzzword. Trả lời "microservices vì scalable hơn" mà không giải thích được cái giá phải trả sẽ lộ ngay là chưa từng làm thật.
Thay vì liệt kê ưu nhược điểm chung chung, hãy trả lời theo 3 lớp:
"Bạn sẽ tách monolith thành microservices như thế nào?" — Đáp án tốt không phải "tách theo layer (UI/logic/data)" mà là tách theo bounded context (khái niệm từ Domain-Driven Design): mỗi service sở hữu trọn vẹn 1 domain nghiệp vụ (Order, Payment, Inventory...), có database riêng, giao tiếp qua API hoặc message queue thay vì share database.
"Làm sao đảm bảo consistency giữa các service?" — Đây là lúc nhắc tới Saga pattern (chuỗi transaction cục bộ, mỗi bước có compensating action nếu lỗi) thay vì distributed transaction (2PC) vốn không thực tế ở scale lớn.
Nếu bạn từng làm việc với hệ thống có cả 2 mô hình, hãy kể cụ thể: dịch vụ nào tách ra, lý do thật sự (không phải "vì trendy"), và vấn đề gặp phải sau khi tách (thường là network failure, cần retry + circuit breaker, hoặc chi phí vận hành tăng do nhiều CI/CD pipeline hơn).
Tránh nói microservices luôn tốt hơn — nhiều công ty lớn (Shopify, Basecamp) chủ động chọn "majestic monolith" và vẫn scale tốt bằng cách module hoá rõ ràng bên trong 1 codebase. Điều nhà tuyển dụng muốn nghe là bạn biết khi nào chọn cái nào, không phải bạn ủng hộ 1 phe.