Một bản thiết kế đẹp trên giấy chưa nói lên điều gì cả — giá trị thật nằm ở việc bạn tìm ra nó sẽ vỡ ở đâu, trước khi khách hàng tìm ra giúp bạn.
Từ Yêu Cầu Đến Bản Vẽ Kiến Trúc Đầu Tiên
Bạn đã bao giờ ngồi trước trang trắng, đầu đầy yêu cầu nghiệp vụ nhưng chưa biết vẽ box nào trước chưa? Cái khó không phải là vẽ ra một sơ đồ — ai cũng vẽ được vài ô vuông nối bằng mũi tên. Cái khó là vẽ đúng thứ, đúng mức độ chi tiết, phản ánh đúng ràng buộc thực tế.
AI phát huy giá trị đầu tiên ở đây: biến danh sách yêu cầu rời rạc thành bản nháp kiến trúc có cấu trúc, nhanh hơn nhiều so với tự vẽ. Nhưng "nhanh" không phải lý do duy nhất — quan trọng hơn, AI ép bạn phải nói rõ ràng buộc ngay từ đầu. Không cho nó biết traffic dự kiến, budget, hay SLA, nó sẽ tự bịa giả định, và bạn thấy ngay chỗ mình chưa nghĩ tới.
Lấy một ví dụ xuyên suốt bài này để bạn dễ hình dung: một hệ thống URL shortener quy mô lớn (kiểu bit.ly), phải chịu được 50,000 request/giây ở thời điểm cao điểm, với yêu cầu redirect phải nhanh dưới 50ms. Đây là bài toán kinh điển trong phỏng vấn system design, nhưng cũng là bài toán thật — Bitly, TinyURL đều phải giải quyết đúng những vấn đề này ở quy mô sản xuất.
Prompt mẫu để bắt đầu:
Tôi cần thiết kế một URL shortener service ở quy mô lớn với các yêu cầu sau:
- 50,000 requests/second ở peak, tỷ lệ read:write là 100:1
- Redirect latency phải dưới 50ms ở P99
- Short code dài 7 ký tự, không được trùng
- Cần analytics cơ bản: đếm số click theo URL, theo thời gian
- Budget hạ tầng: trung bình, ưu tiên dùng managed service trên AWS
Hãy đề xuất kiến trúc high-level, gồm:
1. Các thành phần chính (service, database, cache, queue...)
2. Lý do chọn từng thành phần, kèm 1-2 phương án thay thế đã cân nhắc
3. Ước tính capacity: bao nhiêu server, bao nhiêu storage, chi phí ước tính
4. Vẽ sơ đồ dạng Mermaid diagram (component diagram)
Đừng vội đưa ra một giải pháp duy nhất — hãy hỏi lại tôi nếu thiếu thông tin quan trọng.
Để ý dòng cuối: "hãy hỏi lại tôi nếu thiếu thông tin quan trọng". Chi tiết nhỏ nhưng quan trọng — một AI agent tốt (Claude Code, Cursor) khi được yêu cầu vậy sẽ hỏi ngược lại về điểm mơ hồ, ví dụ "custom short code có được phép không?", "cần multi-region không?" — thay vì tự đoán và vẽ ra kiến trúc sai lệch với ý định thật của bạn.
Bản nháp đầu tiên cho URL shortener thường có: tầng API stateless sau load balancer, cache layer (Redis) tra cứu redirect nhanh, database chính (key-value store hoặc Postgres với sharding) lưu mapping, và một service riêng sinh short code (base62 encoding trên counter, hoặc hash). Đây là baseline hợp lý — nhưng chỉ là điểm khởi đầu để bạn bắt đầu "vặn" nó.
Mẹo: Đừng bao giờ chấp nhận bản nháp đầu tiên. Luôn thêm ràng buộc "hãy liệt kê rõ giả định bạn đang dùng" vào prompt — AI thường âm thầm giả định traffic đồng đều, không có spike, không có hot key, điều này gần như luôn sai trong thực tế.
Adversarial Stress-Testing: Đặt Câu Hỏi Khó
Bản nháp kiến trúc chỉ là hiệp một. Hiệp hai — và cũng là hiệp quan trọng hơn — là biến chính AI từ người vẽ thiết kế thành người công kích thiết kế đó. Đây gọi là adversarial stress-testing (kiểm thử đối kháng): bạn chủ động yêu cầu AI đóng vai một kỹ sư khó tính, một reviewer từng bị cháy production, để tìm lỗ hổng trong chính thiết kế nó vừa đề xuất.
Tại sao phải làm việc này? Vì một AI, cũng giống một kỹ sư junior đang hào hứng, có xu hướng trình bày thiết kế theo hướng "mọi thứ đều ổn". Nó sẽ không tự nhắc bạn rằng cache của bạn sẽ tạo ra một single point of failure (điểm lỗi duy nhất — nếu thành phần này chết thì cả hệ thống chết theo), trừ khi bạn ép nó phải tìm ra chuyện đó.
Prompt mẫu cho bước stress-test:
Bây giờ hãy đóng vai một Staff Engineer đã từng vận hành hệ thống ở quy mô lớn,
đang review thiết kế URL shortener ở trên trong một buổi architecture review nghiêm khắc.
Hãy công kích thiết kế này với tinh thần "tìm lỗi trước khi launch":
1. Điểm nào trong thiết kế sẽ sập đầu tiên khi traffic tăng gấp 10 lần?
2. Điều gì xảy ra nếu database chính bị down 5 phút?
3. Điều gì xảy ra nếu một short URL trở thành viral (nhận 10,000 click/giây)?
4. Có race condition nào khi nhiều request cùng tạo short code không?
5. Chi phí sẽ tăng theo cách nào không tuyến tính khi traffic tăng?
Với mỗi vấn đề, đánh giá mức độ nghiêm trọng (Critical/High/Medium) và
đưa ra ít nhất một hướng khắc phục cụ thể.
Kết quả trả về thường sẽ trông như thế này (rút gọn):
1. [CRITICAL] Cache miss storm: nếu Redis restart hoặc bị evict toàn bộ,
toàn bộ traffic đổ thẳng vào database chính -> database sập theo
hiệu ứng domino (cache stampede).
Đề xuất: thêm cache warming, hoặc dùng request coalescing.
2. [CRITICAL] Nếu database chính down, toàn bộ redirect (read path) cũng
chết theo, vì thiết kế hiện tại route mọi read qua cùng một DB instance
dù 99% traffic là read. Đây là single point of failure rõ ràng nhất.
Đề xuất: read replica, hoặc tách hẳn write path và read path.
3. [HIGH] Một short URL viral tạo ra "hot key" — toàn bộ 10,000 req/s dồn
vào đúng 1 cache key, có thể vượt quá khả năng của 1 Redis node dù
cluster tổng vẫn còn dư tải.
Đề xuất: local in-memory cache (L1) trước Redis (L2) cho hot key.
4. [MEDIUM] Race condition khi 2 request cùng generate short code trùng
counter value (nếu dùng counter-based approach mà không có
distributed lock hoặc counter range pre-allocation).
5. [MEDIUM] Chi phí Redis tăng phi tuyến nếu bạn giữ toàn bộ mapping trong
cache thay vì chỉ cache hot data với TTL + eviction policy hợp lý.
Nhìn kỹ danh sách trên, bạn sẽ thấy nó không phải là những phê bình chung chung kiểu "cần thêm monitoring" — nó chỉ ra chính xác component nào, tình huống nào, và vì sao. Đó mới là stress-test có giá trị. Nếu AI trả lời quá mơ hồ, hãy hỏi tiếp "Cụ thể hơn: dòng traffic nào chạm vào component X trong tình huống Y?"
Mẹo: Yêu cầu AI trả lời theo format bắt buộc (severity + root cause + fix) thay vì văn xuôi tự do. Format ép AI phải suy luận có cấu trúc thay vì liệt kê hời hợt, và giúp bạn dễ dàng sắp xếp thứ tự ưu tiên xử lý.
Tìm Single Point of Failure và Scalability Bottleneck
Sau bước công kích tổng quát, bước tiếp theo là đào sâu có hệ thống vào hai loại lỗi nguy hiểm nhất trong mọi kiến trúc: single point of failure (SPOF — điểm lỗi duy nhất khiến cả hệ thống ngừng hoạt động) và scalability bottleneck (nút thắt cổ chai khi traffic tăng, thành phần không scale kịp).
Hai loại này khác nhau về bản chất. SPOF là câu hỏi "nếu X chết, cái gì chết theo?". Bottleneck là câu hỏi "nếu traffic tăng N lần, cái gì sập trước?". Một thiết kế có thể không SPOF nào nhưng vẫn bottleneck nghiêm trọng, và ngược lại.
Với ví dụ URL shortener, đây là prompt để đào sâu riêng vào hai vấn đề này:
Vẽ lại kiến trúc URL shortener, đánh dấu rõ:
- Mọi single point of failure (component mà nếu chết sẽ làm cả hệ thống
hoặc một phần quan trọng ngừng hoạt động)
- Mọi scalability bottleneck (component không scale ngang được, hoặc scale
được nhưng chi phí/độ phức tạp tăng phi tuyến)
Với mỗi điểm, cho biết: mức traffic nào sẽ làm nó vỡ, và có approach nào
trong các hệ thống thực tế (Bitly, TinyURL, Discord invite links) đã giải
quyết vấn đề tương tự chưa.
Ví dụ kết quả cho hệ thống này thường lộ ra những điểm sau:
- SPOF #1: short-code generator nếu chạy dạng single counter service (không phân tán) — mọi write phải qua đúng 1 instance để đảm bảo không trùng code. Nếu instance đó chết, toàn bộ write path (tạo URL mới) ngừng hoạt động.
- SPOF #2: nếu chỉ có 1 database region, một sự cố region-level (AWS us-east-1 down) làm chết toàn bộ hệ thống, kể cả read path.
- Bottleneck #1: nếu short-code generator dùng auto-increment ID trên 1 DB duy nhất, số lượng short code sinh ra mỗi giây bị giới hạn bởi write throughput của DB đó — thường vài nghìn/giây, không đủ nếu viral event khiến hàng loạt link được tạo cùng lúc.
- Bottleneck #2: nếu analytics (đếm click) ghi trực tiếp vào cùng DB với mapping chính, mỗi lần redirect sẽ kèm theo 1 write — write load tăng tuyến tính theo read load, phá vỡ giả định "read-heavy nên chỉ cần scale read".
Cái hay ở bước này là AI thường tự liên hệ cách các hệ thống thật đã giải quyết — ví dụ gợi ý pre-allocated ID ranges cho mỗi generator instance (giống Instagram sinh ID phân tán), hoặc tách write path analytics khỏi critical path bằng message queue, ghi async.
Mẹo: Luôn hỏi riêng "điểm này vỡ ở traffic bao nhiêu?" thay vì chỉ hỏi "có bottleneck không". Con số cụ thể (ví dụ "vỡ ở khoảng 8,000 write/s") giúp bạn biết đây là vấn đề cần xử lý ngay hay để dành cho giai đoạn sau.
Lặp Lại Thiết Kế Dựa Trên Điểm Yếu AI Tìm Ra
Tìm ra vấn đề chỉ là nửa việc. Nửa còn lại — thể hiện năng lực kỹ sư thật sự của bạn — là quyết định sửa cái gì trước, sửa thế nào, và đánh đổi ra sao. Đây là lúc trade-off (đánh đổi) trở thành từ khóa trung tâm: mọi giải pháp sửa lỗi đều tạo chi phí mới, dù là vận hành, độ phức tạp, hay tiền bạc.
Quay lại 2 SPOF vừa tìm được ở bước trước: short-code generator là single point of failure, và write path bị bottleneck bởi auto-increment. Thay vì hỏi AI "sửa hộ tôi", hãy hỏi nó đề xuất nhiều phương án và so sánh:
Với vấn đề short-code generator là SPOF và bottleneck (auto-increment
trên 1 DB), hãy đề xuất 3 phương án khắc phục khác nhau. Với mỗi phương án,
liệt kê: độ phức tạp triển khai, chi phí vận hành thêm, và trade-off cụ thể.
Sau đó khuyến nghị 1 phương án phù hợp nhất cho use case:
50,000 req/s, 100:1 read:write, team gồm 4 backend engineer, không có
dedicated SRE team.
Kết quả thường đưa ra 3 hướng rõ rệt: (1) dùng Snowflake-style distributed ID generator — phức tạp triển khai cao, nhưng scale vô hạn và không SPOF; (2) pre-allocate range ID cho từng service instance (mỗi instance được cấp một dải 1 triệu ID để tự sinh không cần hỏi trung tâm) — độ phức tạp trung bình, cân bằng tốt; (3) random string + kiểm tra trùng bằng bloom filter — đơn giản triển khai nhất nhưng phải chấp nhận một tỷ lệ retry nhỏ khi trùng.
Với đội chỉ 4 backend engineer, không SRE riêng, AI thường khuyến nghị phương án (2) — cân bằng độ phức tạp vận hành và khả năng scale, không đòi hỏi coordination phức tạp như Snowflake. Đây là lúc bạn, với tư cách senior, tự đánh giá lại: team có kế hoạch scale 10x trong 6 tháng tới không? Nếu có, đầu tư phương án phức tạp hơn ngay từ đầu có thể rẻ hơn so với migrate sau khi đã chạy production.
Sau khi chọn phương án, đừng dừng lại — yêu cầu AI cập nhật sơ đồ kiến trúc và chạy lại vòng stress-test ở bước 2, để xác nhận vấn đề thực sự được giải quyết, chứ không chỉ bị che giấu.
Mẹo: Luôn yêu cầu AI liệt kê ít nhất 3 phương án thay vì 1, kèm trade-off rõ ràng — nếu chỉ hỏi "sửa hộ", AI có xu hướng chọn giải pháp phổ biến nhất trên internet, chưa chắc phù hợp với ràng buộc thật của team bạn.
So Sánh Thiết Kế AI Tạo Ra Với Các Pattern Đã Biết
Một trong những cách nhanh nhất kiểm chứng chất lượng thiết kế AI đưa ra không phải tự soi từng chi tiết, mà hỏi ngược: "thiết kế này giống pattern kiến trúc nào đã được cộng đồng kiểm chứng, và khác ở đâu?" Đây là sanity-check hiệu quả, vì các pattern như CQRS (Command Query Responsibility Segregation — tách biệt luồng ghi và đọc), event sourcing (lưu lại toàn bộ chuỗi sự kiện thay đổi trạng thái thay vì chỉ lưu trạng thái cuối cùng), circuit breaker (ngắt mạch — tự động cắt kết nối tới dịch vụ đang lỗi để tránh lỗi lan rộng), saga pattern (điều phối transaction phân tán qua nhiều service bằng chuỗi sự kiện bù trừ), sharding (chia nhỏ dữ liệu theo phân vùng để scale ngang), read replica (bản sao chỉ đọc của database chính, dùng để gánh bớt tải đọc), hay CDN caching đều đã được hàng nghìn hệ thống thực chiến kiểm nghiệm qua nhiều năm.
Với ví dụ URL shortener, một câu hỏi so sánh hợp lý:
Thiết kế URL shortener hiện tại của tôi (đính kèm ở trên) gần giống pattern
kiến trúc nào nhất trong các pattern phổ biến: CQRS, sharding theo
hash-based key, read replica với eventual consistency, hay CDN edge caching?
Với mỗi pattern liên quan, hãy chỉ ra:
1. Thiết kế của tôi đã áp dụng đúng tinh thần pattern đó chưa
2. Nếu áp dụng đầy đủ pattern đó, thiết kế sẽ thay đổi thế nào
3. Có nên áp dụng đầy đủ không, hay giữ nguyên bản đơn giản hơn là đủ
Với bài toán này, câu trả lời điển hình sẽ chỉ ra: việc tách write path (tạo short URL) khỏi read path (redirect) chính là tinh thần của CQRS — dù bạn không cần dùng đúng thuật ngữ đó hay triển khai đầy đủ 2 model dữ liệu riêng biệt. Việc dùng Redis cache trước database cho redirect chính là áp dụng read replica / cache-aside pattern ở dạng đơn giản. Còn analytics (đếm click) là ứng viên hoàn hảo cho event sourcing đơn giản — mỗi click là một event được ghi vào queue, xử lý bất đồng bộ, thay vì update trực tiếp một counter.
Bước so sánh này không chỉ để gắn nhãn cho vui — nó giúp bạn tận dụng kho tri thức vận hành có sẵn quanh pattern đó. Nếu bạn nhận ra mình đang làm CQRS dù không cố ý, bạn có thể tra cứu ngay cạm bẫy kinh điển của CQRS (đồng bộ giữa write model và read model bị trễ, khiến user không thấy ngay short URL vừa tạo) và chuẩn bị trước, thay vì tự khám phá lại từ đầu.
Ngược lại, nếu AI đề xuất một pattern quá phức tạp cho quy mô của bạn — ví dụ gợi ý event sourcing đầy đủ với event store riêng cho một hệ thống chỉ 5,000 request/giây — đó là dấu hiệu bạn nên hỏi lại "pattern này có over-engineering cho quy mô hiện tại không?"
Mẹo: Khi AI gắn nhãn thiết kế của bạn với một pattern nổi tiếng, luôn hỏi thêm "known failure mode của pattern này là gì" — đó là cách nhanh nhất để học từ kinh nghiệm hàng nghìn hệ thống khác đã đi trước bạn.
Khi Nào Nghe Theo AI, Khi Nào Nên Bỏ Qua
Đây là câu hỏi không AI nào trả lời thay bạn được, vì nó đòi hỏi context mà AI không có: ngân sách thật, năng lực thật của team, deadline thật, văn hóa vận hành thật. AI liệt kê trade-off được, nhưng quyết định cuối cùng luôn là của bạn — người chịu trách nhiệm khi hệ thống sập lúc 2 giờ sáng.
Khi nào nghe theo AI? Khi vấn đề đã được giải quyết rộng rãi, đồng thuận cao trong ngành — cache trước database cho hệ thống read-heavy, queue để decouple write nặng khỏi critical path, CDN cho static asset. Đây là "best practice" gần như không cần bàn cãi, phản bác chỉ tốn thời gian.
Khi nào nên override (ghi đè, không làm theo)? Có ít nhất ba tình huống kinh điển:
Thứ nhất, khi AI đề xuất giải pháp đúng kỹ thuật nhưng sai ngữ cảnh tổ chức. Ví dụ gợi ý Kubernetes multi-region cho URL shortener — lý thuyết đúng, scale và chịu lỗi tốt hơn. Nhưng team chỉ 4 người, chưa ai vận hành Kubernetes production, thì đây là quyết định giết chết team về vận hành, dù kiến trúc "đẹp" trên giấy.
Thứ hai, khi AI thiếu thông tin ràng buộc kinh doanh không thể hiện trong prompt — công ty đã ký hợp đồng dài hạn với cloud vendor cụ thể, hoặc có yêu cầu compliance riêng (dữ liệu không được rời khỏi một region) mà bạn quên đề cập.
Thứ ba, khi đề xuất tối ưu cho "đúng sách vở" nhưng công ty đang cần tốc độ hơn hoàn hảo. Startup tìm product-market fit không cần kiến trúc chịu 1 triệu request/giây — họ cần ship nhanh, học từ user thật. AI liên tục đẩy bạn về "kiến trúc cho scale lớn" là dấu hiệu premature optimization (tối ưu sớm khi chưa cần thiết).
Nguyên tắc thực dụng: coi AI như kỹ sư senior giỏi nhưng chưa từng họp với sếp bạn, chưa biết ngân sách quý này. Nó cho góc nhìn kỹ thuật sắc bén — ghép góc nhìn đó vào bức tranh tổ chức thật là việc của bạn.
Mẹo: Mỗi khi định override đề xuất của AI, hãy tự hỏi ngược lại nó "nếu bỏ qua đề xuất này, rủi ro lớn nhất là gì" — đôi khi câu trả lời khiến bạn đổi ý, đôi khi nó xác nhận bạn đúng.
Thực Hành: Chu Trình Stress-Test Đầy Đủ Cho Một Thiết Kế
Phần này, chạy trọn một chu trình từ đầu đến cuối cho URL shortener, để bạn thấy quy trình vận hành liền mạch thế nào khi làm việc thật với Claude Code hoặc Cursor.
Bước 1 — Vẽ bản nháp đầu tiên. Dùng prompt ở phần 1 (mục tiêu 50,000 req/s, 100:1 read:write, budget trung bình). Yêu cầu AI trả về kiến trúc dạng Mermaid diagram cộng danh sách thành phần.
Kết quả rút gọn: API layer (stateless, sau ALB) → Redis cache → PostgreSQL (bảng mapping short_code -> long_url) → một service riêng sinh short code bằng auto-increment + base62 encode.
Bước 2 — Chạy adversarial stress-test. Dùng đúng prompt "đóng vai Staff Engineer" ở phần 2. AI trả về 5 vấn đề, trong đó nghiêm trọng nhất là: (a) short-code generator là SPOF kiêm bottleneck, (b) không có read replica nên nếu DB chính down thì redirect cũng chết dù 99% traffic chỉ đọc.
Bước 3 — Đào sâu SPOF/bottleneck cụ thể. Prompt tiếp:
Với vấn đề (a) short-code generator là SPOF/bottleneck: ước tính chính xác
throughput tối đa hiện tại (auto-increment trên 1 Postgres instance) là bao
nhiêu write/giây, dựa trên write latency trung bình của Postgres single-row
insert (~1-3ms). So sánh con số này với yêu cầu thực tế của tôi (500 write/s
ở mức 100:1 read:write trên 50,000 req/s tổng).
Kết quả: AI tính ra 1 Postgres instance thường chịu được 3,000-8,000 simple write/giây tùy cấu hình — cao hơn nhiều so với 500 write/s cần thiết. Đây là phát hiện quan trọng: bottleneck này thực ra chưa phải là vấn đề cấp bách ở quy mô hiện tại, dù vẫn là SPOF cần xử lý về mặt availability.
Bước 4 — Iterate: ưu tiên đúng vấn đề. Prompt điều chỉnh trọng tâm sang availability — vấn đề thật vừa lộ ra ở bước 3:
Vấn đề ưu tiên bây giờ là availability, không phải throughput
(auto-increment vẫn đủ khả năng cho 500 write/s). Hãy đề xuất cách
loại bỏ SPOF của short-code generator mà KHÔNG cần đổi sang distributed
ID generator phức tạp — ví dụ dùng Postgres với failover tự động
(read replica có thể promote), và giữ nguyên auto-increment.
AI đề xuất: dùng Postgres với 1 read replica + automated failover (RDS Multi-AZ hoặc tương đương), giữ nguyên auto-increment cho write vì throughput không phải vấn đề, đồng thời route toàn bộ read (redirect) qua Redis trước rồi mới fallback vào read replica — không chạm vào primary DB cho read path nữa.
Bước 5 — Re-check bằng vòng stress-test thứ hai. Yêu cầu AI chạy lại đúng bộ 5 câu hỏi ở bước 2 trên kiến trúc mới. Lần này kết quả cho thấy SPOF #2 (DB chính down làm chết redirect) đã được giải quyết — vì redirect giờ chỉ phụ thuộc Redis + read replica, không còn phụ thuộc primary. Vấn đề còn tồn đọng: cache stampede (nếu Redis restart toàn bộ) vẫn còn nguyên, trở thành ưu tiên tiếp theo cho vòng lặp kế tiếp.
Bước 6 — Ghi lại quyết định. Đây là bước dễ bị bỏ quên nhất nhưng quan trọng không kém: yêu cầu AI tóm tắt lại toàn bộ quyết định thiết kế cùng lý do, dưới dạng một Architecture Decision Record (ADR) ngắn gọn, để 6 tháng sau khi có người hỏi "tại sao lại chọn thế này", bạn có tài liệu để trả lời thay vì phải nhớ lại từ đầu.
Chu trình này — vẽ, công kích, đo lường, ưu tiên đúng vấn đề, sửa, kiểm tra lại — chính là khuôn mẫu bạn nên lặp lại cho mọi thiết kế hệ thống quan trọng, dù là URL shortener hay hệ thống thanh toán triệu đô.
Mẹo: Luôn chạy lại đúng bộ câu hỏi stress-test ban đầu sau mỗi lần sửa — đừng chỉ hỏi câu hỏi mới. Việc so sánh kết quả trước/sau trên cùng bộ câu hỏi là cách duy nhất để biết chắc bạn đã thực sự giải quyết vấn đề, chứ không phải chỉ dịch chuyển nó sang chỗ khác.
Những điểm chính
- AI giúp bạn đi từ yêu cầu nghiệp vụ tới bản nháp kiến trúc rất nhanh, nhưng bản nháp đầu tiên chỉ là điểm khởi đầu, không phải đáp án cuối.
- Adversarial stress-testing — yêu cầu AI đóng vai reviewer khó tính — là cách hiệu quả nhất để lộ ra điểm yếu mà chính AI vừa che giấu khi trình bày thiết kế "đẹp".
- Phân biệt rõ single point of failure (điều gì chết khi X chết) và scalability bottleneck (điều gì vỡ khi traffic tăng) — đây là hai loại rủi ro khác nhau, cần câu hỏi khác nhau.
- Luôn yêu cầu nhiều phương án kèm trade-off cụ thể khi sửa lỗi, thay vì chấp nhận một giải pháp duy nhất AI đưa ra đầu tiên.
- So sánh thiết kế với các pattern đã biết (CQRS, event sourcing, circuit breaker, saga, sharding, read replica, CDN) giúp bạn tận dụng tri thức vận hành có sẵn và tránh over-engineering.
- Quyết định cuối cùng luôn thuộc về bạn — AI không biết ngân sách, năng lực team, hay văn hóa vận hành thật của công ty bạn.
- Một chu trình stress-test đầy đủ luôn khép kín bằng bước re-check trên cùng bộ câu hỏi ban đầu, để xác nhận vấn đề đã được giải quyết chứ không chỉ bị dịch chuyển.