Team hiểu decision đó rất rõ vào thứ Sáu. Đến thứ Hai, context đã bắt đầu mỏng đi. Người từng ủng hộ thiết kế đơn giản hơn nhớ đến incident risk. Người thích thiết kế linh hoạt hơn nhớ đến roadmap tương lai. Một teammate mới gia nhập sau hai tháng chỉ nhìn thấy shape cuối cùng trong code và tự hỏi vì sao nó hơi lạ.
Architecture decision thường thất bại như memory trước khi thất bại như design. Code vẫn chạy. Test vẫn pass. Nhưng lý do phía sau shape trở nên khó phục hồi. Khi điều đó xảy ra, mỗi refactor bắt đầu giống archaeology. Mọi người hỏi boundary này có chủ ý không, compromise này còn cần không, hay dependency lạ kia là bug mặc áo lịch sử.
Một decision note không cần quá lớn. Nó có thể là ADR ngắn, một design comment trong repo, hoặc một section nhỏ trong spec. Những phần hữu ích khá ổn định: câu hỏi nào đang được trả lời, option nào được chọn, option nào bị loại, vì sao team chọn hướng này, debt nào được chấp nhận, và signal nào sẽ kích hoạt revisit.
Những option bị từ chối quan trọng hơn nhiều team nghĩ. Nếu không có chúng, người đọc tương lai có thể lặp lại cùng cuộc tranh luận với ít context hơn. Một note giải thích vì sao team tránh shared database, trì hoãn queue, hay giữ module trong monolith có thể tiết kiệm nhiều giờ tự tin tái khám phá. Nó cũng giúp team trung thực hơn về uncertainty: đây là câu trả lời tốt nhất với size, traffic, deadline và operational skill lúc đó.
Architecture memory tốt bảo vệ con người, không chỉ bảo vệ code. Nó giúp newcomer hỏi câu tốt hơn mà không thấy mình đang challenge cá nhân ai. Nó giúp maintainer thay đổi decision mà không cần giả vờ team cũ bất cẩn. Nó cho reviewer một artifact chung thay vì dựa vào người nói tự tin nhất trong meeting.
Decision note mạnh nhất được viết gần lúc làm việc thật. Nếu đợi project xong mới viết, nó thành lịch sử đã được đánh bóng. Nếu viết khi trade-off còn mới, nó giữ lại những fact nhỏ hiếm khi sống sót: deadline của customer, incident khiến team cẩn trọng, migration path quá đắt, hoặc test gap khiến shortcut không chấp nhận được.
Tôi thích kết thúc note bằng một revisit trigger. Nếu traffic vượt ngưỡng này, revisit. Nếu hai team bắt đầu sửa module độc lập, revisit. Nếu integration thêm provider thứ ba, revisit. Cách này giữ decision còn sống mà không làm nó mong manh. Một decision không nên permanent chỉ vì đã được document. Nó nên đủ dễ hiểu để thay đổi an toàn.
Teammate tương lai không cần toàn bộ suy nghĩ của mình. Họ cần đủ context để không xem codebase như bí ẩn. Một architecture decision note nhỏ có thể biến một shape lạ từ confusion thành continuity. Đó thường là khác biệt giữa maintain một hệ thống và dần mất niềm tin vào nó.