Architecture

← Chương trước | Mục lục | Chương sau → 3.1. Problem Statement — bài toán trước khi có giải pháp Hãy bắt đầu từ một tình huống rất thật. Công ty bạn có một hệ thống quản lý đơn hàng. Ban đầu chỉ có một web app nội bộ gọi thẳng vào database. Sau 18 tháng, bức tranh thay đổi: Team mobile cần đọc/ghi đơn hàng từ iOS và Android. Đối tác logistics cần truy vấn trạng thái đơn qua máy chủ của họ. Team data cần kéo dữ liệu định kỳ để làm báo cáo. Một team khác xây admin portal, cũng cần cùng dữ liệu nhưng thao tác khác. Bốn client, bốn ngôn ngữ, bốn vòng đời release khác nhau — tất cả cần truy cập cùng một tập dữ liệu qua HTTP. Câu hỏi kỹ thuật đặt ra: ...

← Chương trước | Mục lục | Chương sau → 1. Problem Statement Hãy bắt đầu bằng một tình huống production quen thuộc. Hệ thống e-commerce của bạn có 40 microservice. Một buổi sáng thứ Hai, sau đợt flash sale, team on-call báo cáo: service checkout gọi service pricing với p99 latency tăng từ 15ms lên 800ms, dù CPU của pricing chỉ 30%. Không có deploy mới. Không có query chậm. Metrics của pricing hoàn toàn bình thường. ...

← Mục lục | Chương sau → 1. Problem Statement: Từ một function call đến một network call Hãy bắt đầu từ một tình huống kinh doanh có thật, không phải từ định nghĩa. Công ty của bạn vận hành một hệ thống thương mại điện tử. Ba năm trước, toàn bộ hệ thống là một monolith viết bằng Go: module order gọi module inventory bằng một function call, module payment gọi module notification bằng một method trên struct. Mọi thứ chạy trong cùng một process, cùng một address space, cùng một failure domain. Một lời gọi hàm mất vài chục nanosecond, không bao giờ “mất gói tin”, không bao giờ trả về một nửa kết quả, và hoặc là cả process sống, hoặc là cả process chết — không có trạng thái lưng chừng. ...