Một bạn mới vào một nền tảng có năm dòng sản phẩm, khoảng 150 supplier code chạy trên chừng 90 tích hợp khác nhau, rồi hỏi một câu rất hợp lý: em nên bắt đầu đọc từ đâu. Câu trả lời thật lòng là đọc không phải chỗ nghẽn, và có đọc cả tháng cũng không giải quyết được gì, vì không ai học được chín mươi cái gì cả. Cái người ta học được là một hình dạng, rồi học phần ngoại lệ của nó.
Đây không phải câu nói cho vui. Đó chính là lý do kiến trúc có hình như bây giờ, và nó nghĩa là những thứ làm hệ thống này vận hành được cũng chính là những thứ làm nó học được.
Hình dạng trước, ngoại lệ sau
Mỗi supplier có đúng một module, viết theo một contract cố định, đăng ký bằng code của nó trong một registry duy nhất. Đọc xong một module là bạn nắm được cái khung mà cả chín mươi cái ngồi trong đó: nền tảng sẽ gọi gì, theo thứ tự nào, và chờ nhận về hình gì. Khác biệt giữa các supplier không rải rác trong code dùng chung — đó là toàn bộ mục đích của contract — nên gặp cái nào xử cái đó, khi có ticket làm nó trở nên liên quan.
Rồi tới ngoại lệ, và đúng hai cái đáng dạy ngay tuần đầu. Thứ nhất là supplier này rơi vào pattern offer nào trong hai pattern có tài liệu: hoặc nó trả về một token duy nhất đặt được N phòng, hoặc giá từng phòng độc lập và danh sách offer là ma trận tổ hợp hợp lệ được tính ra. Không có pattern thứ ba, nên "cái này là loại nào" là câu hỏi có đáp án chứ không phải một cuộc điều tra. Thứ hai là search hotel, flight và car chạy bất đồng bộ — một queue, mỗi supplier một job, một Redis lock, worker ghi vào một cache hash dùng chung cộng một meta hash đánh dấu đã xong, tất cả dưới một deadline tuyệt đối 30 giây — trong khi search tour và transfer chạy đồng bộ trong một process, sau cùng một public contract.
Hai pattern và hai mô hình thực thi là bốn thứ phải giữ trong đầu. Chín mươi tích hợp thì không. Cái tài liệu nói ra điều đó được viết vì lý do kiến trúc, và hoá ra lại là tài liệu onboarding.
Tuần đầu là một cái booking, không phải một danh sách đọc
Việc đầu tiên mình đưa cho bạn mới là chạy trọn luồng booking một lần, bằng tay, trên tài khoản test: login, search, search-by-id, prebook, book, cancel. Không phải đọc về nó. Chạy nó, và nhìn từng bước thật sự làm gì.
Việc này an toàn nhờ một luật vốn sinh ra vì lý do khác: booking test luôn chọn offer rẻ nhất có free cancellation, nên một lượt test thành công có thể gỡ lại mà không mất tiền. Luật an toàn đó đồng thời là giấy phép để một người ngày thứ hai đi làm đã được bấm nút.
Một tiếng như vậy dạy được những thứ không sơ đồ nào dạy nổi. Bạn nhìn thấy search trả về một tỉ lệ tiến độ trước khi trả đủ kết quả, và mô hình bất đồng bộ thôi là một đoạn văn. Bạn nhìn thấy prebook chạy thành công trên một process khác với process đã chạy search, và cái offer ID tổ hợp — source, contract, hotel, uuid, decode ở bước prebook, không có session phía server — thôi là một quyết định thiết kế mà thành thứ vừa xảy ra với chính bạn. Bạn nhìn thấy một supplier trả HTTP 200 với lỗi nằm trong body, và bạn thôi tin status code — bài học mà dân tích hợp trước sau gì cũng học, học luôn từ ngày thứ hai cũng được.
Rồi một module, đọc từ đầu tới cuối
Sau luồng booking: đọc đúng một module supplier, hết từ đầu tới cuối, kể cả mấy đoạn xấu. Không phải lướt qua năm cái. Một cái.
Điểm ở đây là chiều sâu trên một mẫu đại diện. Chín mươi module trả lời cùng những câu hỏi bằng chín mươi thứ tiếng địa phương, mà bạn không nghe ra được tiếng địa phương nếu chưa biết cái câu đó lẽ ra nói gì. Mọi cú gọi provider đều được log kèm request và response, và một cú gọi lỗi có thể bắn lại bằng đúng cái curl mà nền tảng đã gửi — nên module có thể được đọc cùng với traffic thật của nó nằm bên cạnh, một bài tập hoàn toàn khác với đọc chay.
Rồi một thay đổi nhỏ trên supplier thứ hai
Bước ba là một task nhỏ trên một supplier khác — nhỏ đủ để làm xong, thật đủ để merge. Đây là lúc cái contract chứng minh giá trị của nó với tư cách công cụ dạy học: bạn mới bước vào với mô hình dựng từ module một, va đúng những chỗ module hai không đồng ý, và học được rằng mấy chỗ không đồng ý đó nằm trong module chứ không rò ra code dùng chung. Đó là lúc câu "một hình dạng cộng phần ngoại lệ" thôi là câu mình nói trong một buổi họp.
Cái gì làm chuyện này lặp lại được
Ba thứ, không thứ nào là một bài hướng dẫn.
Runbook chạy được. Khoảng bảy mươi quy trình nằm rải ba repo tồn tại dưới dạng command chứ không phải trang wiki, nên một bạn chưa biết cách dựng lại một booking hỏng vẫn dựng lại được. Hướng dẫn viết bằng chữ mục ruỗng trong im lặng; một command chạy được thì hoặc đúng, hoặc hỏng lộ ra ngay.
Một handbook nêu yêu cầu, không kể chuyện. Một tích hợp mới phải thoả những gì — khai báo pattern nào, log những gì, báo lỗi ra sao — viết dưới dạng những điều phải thoả. Bạn mới tự đối chiếu được việc của mình mà không cần hỏi mình đã xong chưa.
Nhãn blast-radius nằm ngay trong mục lục. Trong một pack, 17 command chỉ đọc, 6 command ghi vào production và 1 command deploy, đánh dấu 🟢/🟠/🔴 ở chỗ người ta chọn, chứ không nằm trong thân bài để đọc xong mới biết. Bạn mới chắc chắn sẽ đoán mò trong vài tuần; mấy cái nhãn làm cho những lần đoán đó là đoán an toàn. Nguyên tắc y hệt áp cho database: client tiêu chuẩn không vào được database của gateway, nên ai cũng dùng một script query, ở đó SELECT chạy ngay còn lệnh ghi phải confirm rõ ràng sau khi in ra nó sắp ghi vào host nào.
Thứ mình chưa đo
Mình không có con số thời gian onboarding. Không ai bấm giờ tới lần merge đầu tiên, trước hay sau khi mấy thứ này tồn tại, nên mình không nói được là nó nhanh lên — chỉ nói được rằng trình tự bây giờ giống nhau với từng người, và không phụ thuộc vào tuần đó ai trong bọn mình đang rảnh. Nếu ai đưa cho mình một con số "bao nhiêu ngày để làm được việc" cho một hệ thống kiểu này, câu hỏi đầu tiên của mình là họ định nghĩa "làm được việc" là gì.