Trên bảng trắng còn vết bút của buổi họp hôm qua. Một người vẽ ba ô cho thiết kế mới, định thêm ô thứ tư rồi dừng lại. Câu hỏi không chỉ là sơ đồ này có gánh được feature sắp tới hay không. Câu khó hơn là: sau khi ba nhóm khác cùng phụ thuộc vào quyết định này vào quyết định này, ta còn đủ chỗ để sửa quyết định hôm nay chứ?
Nhiều quyết định kiến trúc phình to trước khi bài toán được hiểu đủ. Một tài liệu cố chốt cùng lúc tên gọi, boundary, storage, quyền sở hữu, cách rollout và cả migration trong tương lai. Trông rất nghiêm túc, nhưng nó gói nhiều giả định thành một khối. Chỉ cần một giả định đổi, việc đụng vào cả khối đã tốn chi phí kỹ thuật lẫn chi phí thuyết phục.
Một quyết định nhỏ có đường biên rõ hơn. Nó ghi điều đang được quyết bây giờ, điều cố ý chưa quyết, invariant nào cần bảo vệ và tín hiệu nào sẽ khiến nhóm mở lại lựa chọn. Phần cuối thường bị quên. Không có điều kiện xem lại, sáu tháng sau mọi người khó biết phương án vẫn phù hợp hay chỉ đang được giữ vì nó từng đi qua một cuộc họp đông người.
Ví dụ, một nhóm có thể chốt interface của repository trước khi tuyên bố xong chiến lược lưu trữ lâu dài. Ghi chú có thể nói: use case cần một contract ổn định; PostgreSQL là cách triển khai hiện tại; nếu lưu lượng truy vấn hoặc yêu cầu tenant isolation thay đổi, nhóm sẽ xem lại indexing và storage mà không làm vỡ contract ở handler. Đây vẫn là kiến trúc, chỉ không giả vờ rằng bằng chứng hôm nay đã trả lời luôn tương lai.
Nhỏ không có nghĩa là mơ hồ. Quyết định vẫn phải chỉ ra boundary nào sở hữu hành vi nào, dữ liệu nào là nguồn sự thật, trade-off nào đã chấp nhận và failure mode nào không được phép xảy ra. Invariant cần chắc; chi tiết có thể thay nên được gọi đúng là chi tiết có thể thay. Nếu không tách hai phần, nhóm hoặc thay nhầm nền móng, hoặc giữ luôn cả giàn giáo.
Điều này càng quan trọng khi hệ thống lớn lên qua nhiều thế hệ thành viên. Người mới không chỉ cần đọc code; họ cần biết phần nào đang chịu tải thật và phần nào là lựa chọn tạm vì thời gian, dữ liệu hoặc công cụ lúc đó. Khi mọi quyết định đều được viết với cùng một giọng chắc nịch, người đọc không biết thay đổi ở đâu là an toàn. Một decision note nhỏ giúp phân biệt ý định thiết kế với tai nạn lịch sử.
Kỷ luật thực tế khá gọn: ghi ngày, người sở hữu, ví dụ khiến quyết định trở nên cần thiết, phương án đã cân nhắc, điều chưa chốt và điều kiện làm lựa chọn hiện tại hết đúng. Link tới bằng chứng nếu có. Sau đó tiếp tục làm việc. Nhóm không cần một bộ nhớ kiến trúc hoàn hảo; nhóm cần đủ dấu vết để lần sau không phải khởi động cuộc tranh luận từ lời truyền miệng.
Kiến trúc không yếu đi vì một quyết định có cửa quay lại. Nó chỉ thừa nhận hệ thống sẽ gặp thêm dữ liệu, tải, con người và ràng buộc mà hôm nay chưa thấy. Tôn trọng lý lẽ của hôm qua không đồng nghĩa phải sống mãi trong giới hạn của hôm qua. Một quyết định tốt vừa bảo vệ được phần cần chắc, vừa để lại tay nắm cho lần học tiếp theo.