Các quyết định về kiến ​​trúc và thiết kế code hệ thống với AI

Quyết định ám ảnh bạn

Trong bài học trước, chúng ta đã tìm hiểu về việc tạo tài liệu và chia sẻ kiến thức. Bây giờ, hãy xây dựng trên nền tảng đó. Mỗi nhà phát triển đều có một vấn đề: Một quyết định về kiến ​​trúc tưởng chừng như đúng đắn vào thời điểm đó nhưng lại trở thành cơn ác mộng sau đó. Việc di chuyển microservices làm tăng độ phức tạp lên gấp 3 lần. Cơ sở dữ liệu NoSQL không thể xử lý các yêu cầu báo cáo. Kiến trúc hướng sự kiện "đơn giản" đã tạo ra địa ngục gỡ lỗi.

Những quyết định này rất tốn kém để đảo ngược. Một lựa chọn công nghệ sai có thể tiêu tốn hàng tháng trời về mặt kỹ thuật. Và phần tồi tệ nhất là bạn thường không biết điều đó sai cho đến khi tập trung sâu vào các vấn đề sản xuất.

AI sẽ không đưa ra những quyết định này cho bạn - và bạn không muốn điều đó xảy ra. Nhưng nó có thể làm được điều gì đó cực kỳ có giá trị: Đưa ra những đánh đổi mà bạn chưa từng cân nhắc, các dạng lỗi bề mặt mà bạn chỉ phát hiện ra trong quá trình sản xuất và giúp bạn suy nghĩ thấu đáo về những tác động bậc hai của từng tùy chọn.

Cách quyết định kiến trúc

Dưới đây là cách sử dụng AI cho các quyết định về kiến trúc:

Bước 1: Xác định không gian vấn đề

📍 Nơi dán: Mở ChatGPT (chat.openai.com), Claude (claude.ai) hoặc Gemini (gemini.google.com) và bắt đầu một cuộc trò chuyện mới.

📋 Cách sao chép prompt này: Nhấp vào bất kỳ đâu bên trong khối màu xám, nhấn Cmd+A rồi Cmd+C (Mac) hoặc Ctrl+A rồi Ctrl+C (Windows). Hoặc sử dụng biểu tượng sao chép xuất hiện.

Chúng ta cần thiết kế hệ thống thông báo cho ứng dụng SaaS của mình.

Bối cảnh:
- Hiện có 50.000 người dùng đang hoạt động, tăng 20% hàng tháng
- Các loại thông báo: email, trong ứng dụng, đẩy, SMS
- Người dùng định cấu hình tùy chọn cho mỗi loại thông báo
- Một số thông báo quan trọng về thời gian (cảnh báo bảo mật)
- Một số được chia theo đợt (tiêu hóa hàng ngày)
- Phải hỗ trợ theo dõi phân phối và thử lại logic
- Nhóm: 4 nhà phát triển phụ trợ, tất cả đều mạnh về Python
- Ngăn xếp hiện tại: Django, PostgreSQL, Redis, AWS

Những quyết định kiến trúc quan trọng mà chúng ta cần thực hiện là gì?

✏️ Cách điền thông tin chi tiết của bạn: Thay thế từng [] và trình giữ chỗ trong ngoặc bằng thông tin cụ thể từ tình huống thực tế của bạn. Đầu vào mơ hồ tạo ra đầu ra mơ hồ - hãy cụ thể.

👀 Những gì bạn sẽ thấy: Trong vòng vài giây, AI sẽ trả về phản hồi có cấu trúc dựa vào prompt ở trên. Hãy đọc kỹ và coi nó như một bản nháp chứ không phải là câu trả lời cuối cùng.

✨ Việc cần làm với kết quả đầu ra: Lưu phản hồi vào file Notes. Chọn một đề xuất có đòn bẩy cao nhất và thực hiện nó trong tuần này — đừng thử mọi thứ cùng một lúc.

⚠️ Nếu thấy không đúng: Nếu các đề xuất có vẻ chung chung, hãy dán nội dung này: "Hãy cụ thể hơn với bối cảnh thực tế của tôi. Bỏ qua lời khuyên chung chung." Nếu nó bỏ qua các chi tiết chính mà bạn đã cung cấp, hãy hỏi: "Bạn đã bỏ sót [X] trong ngữ cảnh của tôi - hãy thực hiện lại điều đó như một hạn chế chính."

AI xác định các điểm quyết định:

• Xử lý đồng bộ và không đồng bộ

• Lựa chọn công nghệ xếp hàng đợi

• Cơ sở dữ liệu cho trạng thái thông báo

• Dịch vụ phân phối (xây dựng so với mua)

• Chiến lược xử lý thử lại và xử lý lỗi

Bước 2: Khám phá các lựa chọn với sự đánh đổi

Đối với mỗi điểm quyết định, hãy yêu cầu AI đưa ra các phương án:

Đối với hàng đợi thông báo của chúng tôi, hãy so sánh các tùy chọn này
dựa trên các ràng buộc của chúng tôi (nhóm Python, AWS, 50 nghìn người dùng
tăng trưởng 20%/tháng):

1. Celery với Redis
2. AWS SQS với Lambda
3. RabbitMQ
4. Kafka

Đối với mỗi lựa chọn, hãy phân tích:
- Sự phức tạp trong việc thực hiện và duy trì
- Khả năng mở rộng trần
- Chế độ thất bại và phục hồi
- Chi phí hoạt động ở quy mô của chúng tôi
- Đường cong học tập cho nhóm Python của chúng tôi
- Điều gì xảy ra khi chúng tôi đạt được 500 nghìn người dùng?

AI tạo ra sự so sánh kỹ lưỡng:

Chỉ riêng bảng này đã tiết kiệm hàng giờ nghiên cứu. Nhưng giá trị thực sự nằm ở những chi tiết nhỏ mà AI bổ sung - ví dụ như việc chỉ ra rằng Celery + Redis là giải pháp nhanh nhất để triển khai nhưng lại có vấn đề đã biết với việc xác nhận tin nhắn khi tải nặng, hoặc SQS + Lambda gây ra độ trễ khởi động nguội, điều này rất quan trọng đối với các cảnh báo bảo mật cần phản hồi nhanh chóng.

Kiểm tra nhanh: Tìm ra sự đánh đổi bị thiếu

Một AI đề xuất: "Hãy sử dụng MongoDB để lưu trữ thông báo vì nó xử lý các lược đồ linh hoạt và có khả năng mở rộng theo chiều ngang."

Sự đánh đổi nào bị thiếu trong đề xuất này? Hãy nghĩ về những gì mà thông báo cần nhưng MongoDB lại không được tối ưu hóa.

Mảnh ghép còn thiếu: Thông báo liên quan đến các mẫu truy vấn phức tạp (hiển thị các thông báo chưa đọc cho người dùng X, được sắp xếp theo thời gian). MongoDB có thể xử lý điều này, nhưng nó yêu cầu quản lý chỉ mục cẩn thận. PostgreSQL với các chỉ mục phù hợp thực sự có thể đơn giản hơn cho mẫu truy cập này, và nhóm đã biết điều đó. "Schema linh hoạt" nghe có vẻ tuyệt vời, nhưng schema thông báo thực tế khá ổn định.

Architecture Decision Record (ADR)

Mọi quyết định quan trọng đều nên được ghi lại. AI giúp việc này trở nên dễ dàng hơn:

Hãy giúp tôi viết Architecture Decision Record (ADR) cho
quyết định về hàng đợi thông báo của chúng ta.

Quyết định: Chúng tôi đã chọn Celery + Redis cho Giai đoạn 1, với
lộ trình chuyển đổi sang SQS cho Giai đoạn 2.

Ngữ cảnh: [dán mô tả vấn đề từ Bước 1]

Các lựa chọn đã xem xét:
1. Celery + Redis
2. SQS + Lambda
3. RabbitMQ
4. Kafka

Các yếu tố thúc đẩy quyết định:
- Thời gian đưa sản phẩm ra thị trường nhanh nhất (nhóm đã quen thuộc với Celery)
- Phù hợp với quy mô hiện tại
- Lộ trình chuyển đổi rõ ràng khi chúng ta phát triển

Định dạng: Tuân theo định dạng MADR (Markdown Any Decision Record).

AI tạo ra một ADR có cấu trúc mà bạn có thể xem xét, điều chỉnh và cam kết vào kho lưu trữ của mình. ADR đóng vai trò như bộ nhớ nội bộ — 6 tháng nữa, khi ai đó hỏi "tại sao chúng ta không sử dụng Kafka?", câu trả lời đã được ghi lại.

Thiết kế hệ thống với AI

Đối với thiết kế hệ thống mới, AI hoạt động tốt nhất với vai trò là đối tác tư duy. Đây là một tình huống thực tế:

Chúng tôi đang thiết kế một trình soạn thảo tài liệu cộng tác thời gian thực
(khái niệm tương tự như Google Docs). Hãy giúp tôi suy nghĩ về
kiến trúc của nó.

Các ràng buộc:
- Phải hỗ trợ 50 người chỉnh sửa đồng thời trên mỗi tài liệu
- Các thay đổi hiển thị trong vòng 200ms cho những người chỉnh sửa khác
- Phải xử lý việc giải quyết xung đột
- Chỉnh sửa ngoại tuyến với đồng bộ khi kết nối lại
- Kích thước tài liệu tối đa 100 trang

Những câu hỏi tôi đang băn khoăn:
1. CRDT so với Operational Transformation (OT) để giải quyết xung đột?
2. Kiến trúc WebSocket cho đồng bộ thời gian thực?
3. Làm thế nào để xử lý tình huống ngoại tuyến/đồng bộ?
4. Chiến lược lưu trữ lịch sử phiên bản?

AI sẽ không thiết kế toàn bộ hệ thống cho bạn, nhưng nó sẽ hướng dẫn bạn giải quyết từng câu hỏi với phân tích cụ thể theo ngữ cảnh. Đối với CRDT so với OT, nó sẽ giải thích rằng CRDT dễ hiểu hơn nhưng tạo ra payload lớn hơn, trong khi OT hiệu quả hơn nhưng khó triển khai chính xác hơn. Nó sẽ tham khảo các ví dụ thực tế — Google Docs sử dụng OT, Figma sử dụng CRDT.

Cụm từ quan trọng cần sử dụng: "Tôi đang bỏ sót điều gì?"

Dựa trên kiến ​​trúc chúng ta đã thảo luận, những chế độ lỗi hoặc trường hợp ngoại lệ nào tôi đang bỏ sót?

AI có thể đưa ra các câu hỏi:

• "Điều gì xảy ra khi hai người dùng ngoại tuyến, cùng chỉnh sửa một đoạn văn, rồi đồng thời kết nối lại?"

• "Bạn xử lý như thế nào khi người dùng có kết nối rất chậm, chậm hơn tài liệu trực tiếp 30 giây?" 

• "Chiến lược của bạn là gì đối với các tài liệu rất dài, nơi việc load toàn bộ trạng thái CRDT mất vài giây?"

Đây là những câu hỏi giúp ngăn ngừa các sự cố phát sinh lúc 2 giờ sáng trong quá trình sản xuất.

Đánh giá công nghệ

Khi đánh giá một công nghệ mới cho hệ thống của bạn:

Chúng tôi đang xem xét việc thêm GraphQL vào API REST hiện có.

Tình hình hiện tại:
- 30 REST endpoint phục vụ giao diện người dùng React
- Ứng dụng di động sẽ ra mắt trong 3 tháng tới (cần cùng dữ liệu, nhưng định dạng khác nhau)
- Nhóm 6 người, không có kinh nghiệm về GraphQL
- Sử dụng Express.js, PostgreSQL

Đánh giá GraphQL cho tình huống của chúng tôi:
1. Nó sẽ giải quyết những vấn đề cụ thể nào?
2. Nó sẽ tạo ra những vấn đề mới nào?
3. Lộ trình chuyển đổi từ API REST hiện tại của chúng tôi là gì?
4. Thời gian thực tế bao gồm cả đường cong học tập là bao nhiêu?
5. Có những giải pháp thay thế nào giải quyết cùng những vấn đề đó với ít gián đoạn hơn?

AI cung cấp cho bạn một đánh giá cân bằng. Nó có thể chỉ ra rằng vấn đề "định dạng dữ liệu khác nhau cho thiết bị di động" cũng có thể được giải quyết bằng REST + lựa chọn trường (như JSON:API sparse fieldsets), không yêu cầu đường cong học tập. GraphQL rất tuyệt vời, nhưng nó không phải là giải pháp duy nhất - và AI giúp bạn nhìn thấy các giải pháp thay thế.

Bài tập thực hành: Ghi lại một quyết định

Hãy nghĩ về một quyết định kiến ​​trúc mà bạn vừa đưa ra (hoặc cần đưa ra). Hãy thử cách này:

1. Mô tả vấn đề và các ràng buộc cho trợ lý AI của bạn

2. Yêu cầu 3 tùy chọn với phân tích đánh đổi

3. Hỏi "Tôi còn chưa nghĩ đến điều gì?" cho mỗi tùy chọn

4. Tạo một ADR (Architecture Decision Reasonable) cho tùy chọn bạn đã chọn (hoặc ưu tiên)

5. Xem lại ADR - AI đã nắm bắt được những đánh đổi mà bạn muốn các thành viên nhóm trong tương lai biết chưa?

Bài tập này mất khoảng 15 phút và tạo ra tài liệu mà nếu làm theo cách thông thường sẽ mất một giờ hoặc hơn.

Những điểm chính cần ghi nhớ

• Sử dụng AI để vạch ra các đánh đổi, chứ không phải để nó đưa ra quyết định thay bạn

• Luôn hỏi về các chế độ lỗi và tác động thứ cấp

• Yêu cầu nhiều tùy chọn với so sánh đánh đổi rõ ràng

• "Tôi còn chưa nghĩ đến điều gì?" là prompt kiến ​​trúc mạnh mẽ nhất của bạn

• Ghi lại các quyết định bằng ADR - AI giúp việc này trở nên dễ dàng

• Đánh giá công nghệ nên bao gồm các lựa chọn thay thế, chứ không chỉ là lựa chọn đang thịnh hành