Cuộc nói chuyện về architecture bắt đầu cạnh một chiếc whiteboard vẫn còn dấu từ buổi họp hôm qua. Một người vẽ ba ô, rồi dừng lại trước khi thêm ô thứ tư. Câu hỏi không chỉ là design này có handle được feature tiếp theo không. Câu hỏi khó hơn là decision mình sắp ghi xuống có còn dễ quay lại sau khi ba team khác phụ thuộc vào nó hay không.
Một số architecture decision trở nên quá lớn trước khi nó thật sự được hiểu. Nó cố settle naming, boundary, storage model, ownership model, rollout path và future migration trong một document rất ấn tượng. Document nhìn có vẻ nghiêm túc, nhưng team âm thầm mất khả năng học tiếp. Khi một assumption đổi, cả decision bỗng trở nên đắt đỏ về mặt chính trị để chạm vào.
Một decision nhỏ có cảm giác khác. Nó nói rõ bây giờ đang quyết định điều gì, cố ý chưa quyết định điều gì, và signal nào sẽ khiến team mở lại lựa chọn này. Phần cuối rất quan trọng. Một decision không có điều kiện revisit dễ biến thành bài kiểm tra trí nhớ. Sáu tháng sau, không ai biết choice đó còn fit hay mọi người chỉ đang bảo vệ nó vì nó từng có một cuộc họp.
Ví dụ, team có thể chọn repository interface trước khi chọn xong persistence strategy cuối cùng. Team có thể ghi: hiện tại cần usecase contract ổn định; PostgreSQL là implementation trước mắt; nếu query volume hoặc áp lực tenant isolation đổi, mình sẽ revisit indexing và storage mà không đổi handler contract. Đó vẫn là architecture. Chỉ là architecture bớt diễn sự chắc chắn.
Nhỏ không có nghĩa là mơ hồ. Một decision có thể revisit vẫn phải gọi tên invariant mà nó bảo vệ. Nó vẫn nên giải thích boundary nào own behavior nào. Nó vẫn cần record trade-off bằng ngôn ngữ rõ. Điểm khác là nó không giả vờ rằng evidence hôm nay đã đầy đủ. Team bảo vệ shape quan trọng mà không khắc mọi chi tiết lên đá.
Thói quen này đặc biệt hữu ích khi hệ thống lớn lên qua nhiều người. Teammate mới không chỉ cần code. Họ cần biết decision nào là load-bearing, decision nào chỉ là scaffolding tạm thời. Nếu choice nào cũng được mô tả với cùng mức tự tin, team không biết thứ gì có thể đổi an toàn. Một decision note nhỏ giúp người đọc sau tách intent khỏi accident.
Kỷ luật nằm ở việc để lại tay nắm cho cuộc nói chuyện tiếp theo. Ghi ngày decision. Gọi tên owner. Link example khiến nó cần thiết. Viết điều kiện khiến nó sai. Rồi đi tiếp. Team không cần một ký ức architecture hoàn hảo. Team cần đủ trace để tiếp tục học mà không phải bắt đầu lại từ lời truyền miệng.
Khi một decision đủ nhỏ để quay lại, architecture bớt giống một verdict và giống stewardship hơn. Team có thể tôn trọng reasoning của hôm qua mà không trung thành với giới hạn của hôm qua. Nếu nhìn vào một architecture choice trong system hiện tại, bạn có biết evidence nào sẽ cho phép team đổi ý không?