System Design

Thử Thách Kỹ Thuật (The Engineering Challenge) Xây dựng một nền tảng logistics hiện đại (như giao đồ ăn, gọi xe, hay quản lý đội xe) đòi hỏi khả năng tính toán khoảng cách và Thời gian Dự kiến Đến nơi (ETA) ở một quy mô khổng lồ. Bài toán $N^2$: Nếu bạn có 1,000 tài xế và 1,000 đơn hàng, việc tính toán khoảng cách giữa mọi tổ hợp (combination) có thể xảy ra sẽ đòi hỏi phải chạy tới 1,000,000 phép tính lộ trình riêng lẻ. Tốc độ: Những phép tính này bắt buộc phải diễn ra trong thời gian thực (dưới 50ms) để đảm bảo trải nghiệm người dùng mượt mà và ngăn không cho các thuật toán phân cuốc (dispatching) bị đứt gánh (timeout). Độ chính xác: Hệ thống phải tính tới các ràng buộc phũ phàng của thế giới thực như đường một chiều, biển cấm rẽ trái, và tình trạng kẹt xe thiên biến vạn hóa (dynamic traffic congestion). Các API điểm-tới-điểm thông thường (như mấy cái request Google Maps API cơ bản) thì quá chậm và quá đắt đỏ để có thể gánh vác việc sản xuất Ma trận Khoảng cách (Distance Matrix) hàng loạt. Bạn cần phải có một Hệ thống Định tuyến (Routing Engine) nội bộ được tối ưu hóa đến tận răng. ...

← Series hub Next → Trong hai năm qua, làn sóng áp dụng AI trong doanh nghiệp gần như bị chi phối bởi một kiến trúc duy nhất: Tích hợp API với các mô hình đóng khổng lồ (Frontier LLMs). Mặc dù mô hình API-Centric này giúp việc thử nghiệm ý tưởng (PoC) diễn ra nhanh chóng, nó lại nhanh chóng trở thành một gánh nặng khi mở rộng hệ thống ở quy mô Production và phải xử lý dữ liệu nhạy cảm. ...

Mặc dù việc sử dụng AI để viết mã nguồn hoặc trả lời ticket hỗ trợ khách hàng đang trở nên phổ biến, sự chuyển đổi thực sự trong phần mềm doanh nghiệp lại nằm ở các Hệ thống Agentic (Agentic Systems). Chúng ta đang bước ra khỏi kiến trúc monolithic chỉ sử dụng một prompt duy nhất, tiến tới mạng lưới phân tán gồm nhiều AI Agent có khả năng lên kế hoạch, điều phối và thực thi các quy trình làm việc phức tạp một cách tự chủ. ...

Ngành công nghiệp phần mềm đang chứng kiến một cuộc chuyển giao quyền lực lịch sử. Quyền lực đang dần rời khỏi tay những người “chỉ biết gõ code” để chuyển sang những người “biết cách giải quyết vấn đề bằng hệ thống và AI”. Bối Cảnh: Khi “Viết Code” Không Còn Là Kỹ Năng Độc Tôn Trong hơn hai thập kỷ qua, giá trị của một lập trình viên phần lớn được đo lường bằng việc họ am hiểu cú pháp (syntax) ngôn ngữ nào, thành thạo framework nào (React, Angular, Spring Boot, v.v.), và khả năng ghi nhớ các API. ...

Prerequisite: Để hiểu rõ bối cảnh và lý do tại sao chúng ta cần các hệ thống Multi-Agent thay vì Microservices truyền thống, vui lòng tham khảo Kiến Trúc Hệ Thống AI-Native Toàn Diện. Khi mới tiếp cận với GenAI, đa phần lập trình viên đều bắt đầu bằng việc nhồi nhét một khối lượng prompt khổng lồ cho một LLM duy nhất, hy vọng nó sẽ hoàn thành toàn bộ tác vụ. Tuy nhiên, khi hệ thống scale, cách tiếp cận “Single Monolithic Agent” này bộc lộ những điểm yếu chí mạng về hiệu năng, chi phí và khả năng kiểm soát rủi ro. ...

Trong nhiều năm, hình ảnh một lập trình viên tài năng thường gắn liền với tốc độ gõ phím thoăn thoắt, khả năng ghi nhớ hàng tá thư viện API, và việc viết ra những đoạn mã không một lỗi cú pháp. Chúng ta gọi họ là những “Coder” thuần túy. Nhưng khi AI bước vào sân chơi, một sự thật phũ phàng đã hiện ra: Viết code chỉ là phần dễ nhất trong việc xây dựng phần mềm. ...

Khi nhận ra tốc độ gõ code đã bị AI đánh bại (như thảo luận ở Phần 1), một nỗi sợ vô hình bao trùm lên giới lập trình: “Vậy tôi sẽ làm gì nếu AI làm hết?” Câu trả lời nằm ở việc phân định rõ ranh giới: AI không làm “hết”. AI chỉ làm những việc cơ bắp kỹ thuật, còn con người giữ lại phần đầu não và trách nhiệm. Để tối ưu hóa quá trình phát triển phần mềm mà không đánh mất quyền kiểm soát, chúng ta cần kẻ một đường chỉ đỏ giữa “Lãnh địa của Máy” và “Lãnh địa của Người”. ...

Mạng xã hội và các chiến dịch marketing của các hãng công nghệ liên tục tiêm nhiễm vào đầu chúng ta một khái niệm: “10x Developer nhờ AI”. Hình ảnh một lập trình viên nhâm nhi ly cà phê, gõ vài dòng prompt và hoàn thành khối lượng công việc của cả một tuần trong một buổi sáng thật sự rất hấp dẫn. Nhưng sự thật dưới chiến hào (trenches) của các dự án thực tế lại phũ phàng hơn nhiều. AI mang lại một nguồn sức mạnh khổng lồ, nhưng nó tuân theo định luật bảo toàn năng lượng: Thời gian bạn tiết kiệm được khi “gõ code” sẽ bị đòi lại một phần (thậm chí là toàn bộ) ở khâu đọc và bảo trì, nếu bạn không biết cách. ...

Quy trình phát triển phần mềm truyền thống (SDLC) thường được mô tả như một dây chuyền lắp ráp nhà máy. Business Analyst (BA) viết requirement $\rightarrow$ Designer vẽ UI $\rightarrow$ Lập trình viên (Dev) gõ code $\rightarrow$ Quality Assurance (QA) tìm bug $\rightarrow$ DevOps đẩy lên server. Mỗi người ngồi trong một “lô cốt” (silo) riêng và giao tiếp qua những tấm vé Jira. Nhưng AI đã vung chiếc búa tạ đập nát những bức tường này. Khi một BA có thể nhờ AI sinh ra một đoạn code chạy thử (Proof of Concept), và một Lập trình viên có thể nhờ AI viết kịch bản test tự động, ranh giới giữa các vai trò trở nên vô cùng mờ nhạt. ...

Cho đến giờ, chúng ta đã bàn rất nhiều về AI dưới góc nhìn của Lập trình viên và Tester. Nhưng nếu bước vào phòng họp của Ban Giám Đốc (BOD) hay các Giám đốc Công nghệ (CTO), bạn sẽ thấy một lăng kính hoàn toàn khác. Giới chủ (BOD) không quan tâm bạn dùng AI xịn thế nào, hay prompt dài bao nhiêu. Lăng kính của họ được cấu thành từ 3 biến số sinh tử: Chi phí (Cost), Tốc độ ra mắt (Time-to-Market), và Quản trị Rủi ro (Risk Management). ...

Ở Phần 5, chúng ta đã thấy Ban Giám Đốc (BOD) đang ráo riết trang bị hệ thống AI nội bộ để ép KPI năng suất. Lúc này, nếu bạn vẫn cố chấp ngồi gõ từng dòng lệnh từ đầu đến cuối, bạn sẽ bị bỏ lại. Để tồn tại, lập trình viên buộc phải vứt bỏ chiếc áo “Coder” để khoác lên mình chiếc áo “AI Orchestrator” (Người chỉ huy AI). ...

Dù bạn có kỹ năng Prompt Engineering đỉnh cao đến đâu, sớm muộn gì bạn cũng sẽ va phải một bức tường hiện thực: Viết code tạo ra một tính năng thì dễ, nhưng thiết kế một hệ thống chịu tải hàng triệu user thì vô cùng khó. Trong kỷ nguyên mà AI đang làm thay công việc “gõ phím”, System Design (Thiết kế hệ thống) chính là chiếc phao cứu sinh, là vùng “lãnh địa bất khả xâm phạm” giúp bạn không bị đào thải. ...

Đến lúc này, chúng ta đã vẽ ra một viễn cảnh tương đối tươi sáng: Lập trình viên thoát khỏi cảnh gõ code nhàm chán, trở thành Kiến trúc sư hệ thống và điều phối AI. Nhưng viễn cảnh này chỉ đúng với Senior Developers — những người đã có sẵn nền tảng chuyên môn vững chắc để thẩm định độ đúng/sai của mã nguồn. Còn với những lập trình viên mới vào nghề (Fresher/Junior), sự xuất hiện của AI lại vô tình tạo ra một cuộc khủng hoảng đào tạo tồi tệ nhất trong lịch sử: Nghịch lý Junior (The Junior Paradox). ...

Trong 8 phần trước (từ Phần 1: Sự sụp đổ của “Thợ gõ code” đến Phần 8: Nghịch lý Junior), chúng ta đã mổ xẻ việc dùng AI như một công cụ (Tool) để hỗ trợ lập trình viên (tăng năng suất, test code, xử lý legacy). Nhưng ở phần cuối cùng này, chúng ta sẽ lật ngược lại vấn đề. Nhiệm vụ tối thượng của một Kiến trúc sư Hệ thống (AI-Driven Architect) không chỉ là code nhanh hơn, mà là đưa AI vào làm “trái tim” của chính sản phẩm mà mình đang xây dựng. Chúng ta gọi đó là kiến trúc AI-Native Application. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Các mô hình ngôn ngữ lớn (LLMs) giờ đây đã trở thành hàng hóa phổ thông; chiến trường mới hiện nay là việc điều phối các Bầy đàn Tự trị (Autonomous Swarms - hệ thống đa tác nhân) trên Kubernetes. Để vận hành các swarms này an toàn trong năm 2026, các Kỹ sư Nền tảng (Platform Engineers) phải kết hợp lập lịch K8s bậc cao, định danh Zero Trust, và quản lý trạng thái (state management) mạnh mẽ. ...

🇬🇧 Read the English version of this article on tanhdev.com Chào mừng đến với Tech Radar tuần này. Trong số trước, chúng ta đã đi sâu vào Kratos Clean Architecture & Dapr. Hôm nay, chúng ta sẽ thảo luận về một sự chuyển dịch mang tính lịch sử: Kubernetes đã chính thức trở thành Hệ điều hành (OS) cho AI. Hãy cùng điểm lại những tin tức chấn động từ Google Cloud, Microsoft và sự thống trị tuyệt đối của Golang trong 72 giờ qua. ...

🇬🇧 Read the English version of this article on tanhdev.com Chào mừng đến với Tech Radar tuần này. Trong số trước, chúng ta đã khám phá Kratos Clean Architecture & Dapr Pub/Sub. Hôm nay, chúng ta sẽ giải quyết lĩnh vực phức tạp nhất của hệ thống phân tán: Điều phối Trạng thái (Stateful Orchestration). Chúng ta sẽ mổ xẻ cách triển khai Dapr Workflows và mô hình Actor bên trong Kratos. ...

Điều kiện tiên quyết: Đây là Phần 12 của Khóa Học System Design. Mấy bận trước bốc thuốc đắp mảng vách bọc thép (reliability) — hồi này nhào vô xới vật lộn cân đo đong đếm mớ đường dây múa mép (communication protocols) và rập khuôn mớ bã rác (data formats) để bọn microservice đánh tiếng ới gọi nhau (communication). Answer-first: Đao gRPC được gò rèn sắc lẹm cho màn đâm thọc đánh lộn trong nhà giữa lũ microservices nội bộ bằng chiêu băm nát nhồi rác nhị phân Protobuf luồn lách phà phà qua mấy cái ống nước xối xả HTTP/2 hoặc HTTP/3. Lưỡi dao REST thì quen mùi múa chảo quậy đống rác JSON tọng vô họng HTTP/1.1 hoặc HTTP/2 tiêu chuẩn, làm chân culi mặc định cho ba cái kèo giao tiếp thả rông ngoài đường (public APIs). Lão già GraphQL đóng vai thằng chóp bu gom góp vét máng (aggregator) sừng sững gác cửa (API gateway) hay mọc rễ ở chóp BFF, dâng hầu dọn cỗ cho bọn khách khứa (clients) thò vòi chọt đúng khoét trúng lổ mả đồ chơi chúng nó thèm, ngặt nỗi bắt buộc phải đeo cùm xích chặt cái thói ngáo ộp vắt kiệt sức (complexity limits) và nhét tọng mẻ hót DataLoader rúc rác nhồi bọc đặng không kéo rách lủng lổ ngộp thở sập mẹ hầm server. ...

Điều kiện tiên quyết: Đây là Phần 11 của Khóa Học System Design. Mấy hồi trước hì hục xây đắp xương sống lõi cốt (core components) — hồi này vác khiên bọc giáp cho mớ APIs và múa roi quất dẹp loạn bọn khách sộp ùa dâng ngập lụt (traffic spikes) lúc phình bành. Answer-first: Đòn bóp cổ nặn API (API rate limiting) bọc hậu bảo kê ba cái mỏ dịch vụ (backend services) bằng cách siết cổ vặn vòi lượng rác ọc vô (request volume). An ninh phòng thủ bắt buộc xài trò nhồi lô cốt n lớp (layered defense): Tiền đồn Tường Lửa WAF đập vỡ mõm bầy sóng thần dâng lụt trào (volumetric spikes) ngay ngưỡng cửa, Trạm Gác API Gateways cầm trịch vé tàu (credentials) và mâm cỗ (quotas) ở L7, và cuối cùng bọn bảo kê gầm giường (application middleware) nắm chốt siết gắt gao mớ luật mần ăn chi li (fine-grained business limits). Đòi móc mả vạch mặt thằng khách (client identification) thì phải ngậm bùa bắt IP tróc gốc, bảo mật kín kẽ (xài chiêu PROXY protocol hoặc lột sụn bấu vô cái chót X-Forwarded-For chót lọt tận mép phải). ...

Điều kiện tiên quyết: Đây là Phần 10 của Khóa Học System Design. Mấy chương trước cắm đầu cắm cổ dựng giàn giáo cất nóc (architecture) — tới chương này tao sẽ chỉ cho mày cách banh mắt chui tọt vô ruột ngó ngoáy một cái hệ thống đang quẫy đạp sống nhăn và rà bắt mạch tận gốc ba cái bệnh hoạn ệch ạch (performance issues) chốn production. Answer-first: Đồ nghề mỏ hàn pprof (profiler) đúc liền xương tủy của Go dâng tận răng ngón nghề nhấp nháp nếm CPU (CPU sampling), mổ bụng săm soi đống mỡ phân lô (heap allocation analysis), lật nệm soi vết xếp chồng goroutine (goroutine stack inspection), và chỉ điểm ổ kẹt ngẽn (blocking profiler) — bưng bít sẵn sàng phơi ra như mấy cái cổng HTTP endpoints nhởn nhơ móc từ ba cái ổ dịch vụ production đang chạy ro ro mà cực kỳ héo hao tí tẹo tài nguyên (minimal overhead). Trò vác 2 bức hình chụp đống rác RAM (heap) ra cân đo đong đếm so lệch (Heap diff) là chiêu độc trị dứt điểm nhanh gọn lẹ lòi mặt chuột ổ rò rỉ RAM (memory leaks). ...

Điều kiện tiên quyết: Đây là Phần 9 của Khóa Học System Design. Lội lại Phần 4: Phình To Cơ Sở Dữ Liệu đặng thông não mớ nền tảng mấy trò chặt thịt phân mảnh ngang (horizontal partitioning). Answer-first: Đạo luật Băm Nhất Quán (Consistent Hashing) đè ép độ tàn phá xáo trộn chìa khóa (key remapping) xuống mức kịch kim rẻ mạt nhất có thể mỗi bận có thằng bỏ hội hay đứa mới bon chen vào mâm (cluster membership changes). Lỡ bốc nhón thêm/bớt đúng 1 node vào cái ổ băm chia dư (modulo-hash cluster) là y như rằng nó hất cẳng lật tung 100% mâm khóa (catastrophic cache miss storm - bão văng cache). Cái bùa Băm Nhất Quán chọc lòi chỉ cấu xé nắn lại đúng có nhõn phần $K/N$ số lượng khóa — con số rẻ mạt tối hậu trên mặt lý thuyết. ...

Điều kiện tiên quyết: Đây là Phần 8 của Khóa Học System Design. Lục lọi lại Phần 7: Chế Đồ API Cản Đúp trước đi — mớ đòn giao dịch chuộc lỗi (compensating transactions) trong lò Saga bắt buộc phải đính kèm bùa cản đúp (idempotent). Answer-first: Khung rập Saga Pattern cầm trịch giàn xếp mớ bòng bong giao dịch lộn xộn (distributed transactions) vắt ngang dọc bầy microservices bằng ngón đòn băm nát một cục giao dịch chà bá thành một lốc giao dịch lẻ tẻ (local transactions). Lỡ xui một nháy đứt gánh (fails), nguyên hệ thống tự động bóp cò nhả đạn giao dịch chuộc lỗi (compensating transactions) dội ngược theo chiều tua lùi (reverse order) đặng dọn sạch rác (undo) mấy khâu nãy giờ đã dọn mâm xong. Mỗi cục giao dịch cỏn con bắt buộc phải biết cản đúp (idempotent). ...

Điều kiện tiên quyết: Đây là Phần 7 của Khóa Học System Design. Lội ngược dòng Phần 6: Khóa Phân Tán — ba cái trò chặn cửa tụi vãng lai đúp bóng (concurrent duplicate request blocking) múa may chung một mâm pháp bảo trói gô chèn ép (mutual exclusion primitives). Answer-first: Đạo luật cản đúp API (API idempotency) vả vỡ mồm thề sống chết (ensures) phán rằng hễ lỡ tay chọt nút thử lại y boong mớ rác (retrying an identical request - móc chung thẻ Idempotency-Key) thì không bao giờ đẻ thêm trứng rơi vãi họa ngoài lề (additional side effects) lấn quá cái vạch chốt hạ của lần chọc đầu tiên (first execution). Miếng bùa này là thứ lõi móng cốt tử cho mấy cái cống rút tiền (payment APIs) nơi bão mạng đứt gãy bắt ép tụi khách chọc lút cán đập cửa (client retries), và nhỡ rách việc lọt lưới 1 cú nháy đúp (duplicate execution) thì đồng nghĩa với màn phang x2 cướp tiền thiên hạ (double charge). ...

Điều kiện tiên quyết: Đây là Phần 6 của Khóa Học System Design. Bơi ngược lại Phần 5: Kafka & Bám Đuôi Sự Kiện để nhồi nhét mấy cái trò mồi rác sự kiện (event sourcing) trước khi xắn tay vào cùm gông khóa mõm. Answer-first: Đám khóa phân tán (Distributed locks) được đẻ ra để giàn xếp cái nợ đòi độc chiếm cắn xé nhau (mutual exclusion problem) chéo qua vắt lại giữa 1 nùi server độc lập — trói gô lại (ensuring) bắt buộc chỉ chừa đúng nháy 1 thằng server thò mõm vào cắn cấu một bãi rác dùng chung (shared resource) tại 1 thời điểm. Cái bùa Redlock của nhà Redis quăng ra cái ổ khóa chạy bạt mạng đua xe (high-performance) xài chiêu trò kéo bè kéo cánh số đông (majority quorum) rải rác đè đầu mớ node master; Thằng etcd lại vỗ ngực xưng tên ban phát bùa hộ mệnh sống chết chắc nịch (stronger guarantees) nhờ cái giao ước máu Raft (Raft consensus) đổi lại phải nôn tiền trả giá bằng độ lề mề lê lết (higher latency). ...

Điều kiện tiên quyết: Đây là Phần 5 của Khóa Học System Design. Quẹo lội lại Phần 4: Phình To Cơ Sở Dữ Liệu để thấu cái hang ổ lưu trữ (storage tier) nơi đám rác sự kiện lỳ lợm (persisted events) bị quăng xuống. Answer-first: Cấu Trúc Bám Đuôi Sự Kiện (Event-Driven Architecture) giật đứt tung mớ xiềng xích gò bó (decouples services) bằng cái luồng chửi thề chéo hông (asynchronous communication) qua một quyển sổ thù vặt trâu bò (durable message log). Ở xứ Go, mớ goroutines và ống xả có nắp (buffered channels) đẻ ra cái luồng nhịn nhục xả áp bẩm sinh (natural backpressure) — bao giờ tụi bóc rác (consumers) lết lếch lê gối hụt hơi nhặt không kịp đống rác của lũ vãi rác (producers), cái ống xả đầy ụ ứ họng sẽ tự bịt mõm (blocks) thằng xả rác, khóa hầu bao bóp họng dội ngược tốc độ ăn rác (throttling the ingest rate) một cách điêu luyện. ...

Điều kiện tiên quyết: Đây là Phần 4 của Khóa Học System Design. Lội lại Phần 3: Chiến Lược Caching để ngấm mớ luật lệ tầng cache trước khi mò xuống vũng lầy lưu trữ (storage). Answer-first: Đập vụn DB (Database sharding) là màn phân phát dữ liệu dạt sang hai bên sườn (horizontally) rải đều ra mấy cái mảnh vỡ độc lập (independent partitions/shards) bám theo một cái chìa khóa dẫn đường (shard key), cốt để xoa dịu cái màn dẫm đạp chửi bới nhau lúc ghi dữ liệu (reducing write contention) và mở đường cho dung lượng phình to tỷ lệ thuận đâm lủng trần nhà (linear storage growth). Chấm mút chọn sai cái shard key là đẻ ra ngay mấy cái ổ kiến lửa (hot spots) lòi le, hậu quả còn bết bát thảm khốc hơn cả việc chẳng thèm sharding. ...

Điều kiện tiên quyết: Đây là Phần 3 của Khóa Học System Design. Hãy nghiền ngẫm Phần 2: Cân Bằng Tải L4/L7 để hiểu thấu cái mớ bòng bong tầng traffic trước khi nhảy cắm đầu xuống cái vực thẳm caching. Answer-first: Đỉnh cao của nghệ thuật xài bùa (caching strategy selection) phụ thuộc vào hai chữ: bạn chịu đựng được mức sai số đồng bộ (consistency window) bao lâu và cái nết đọc/ghi (read/write access pattern) của cái đống dữ liệu đó thế nào. Ghi-Xuyên-Thấu (Write-Through) là đo ni đóng giày cho mớ sổ sách tiền bạc; Ghi-Lùi-Sau (Write-Behind) lại là chân ái của đám đếm view đếm click hay gom rác phân tích (analytics); Ghi-Vào-Rồi-Đọc (Cache-Aside) thì nghiễm nhiên là trùm cuối (default) cho mấy cái API suốt ngày ngửa cổ chờ đọc dồn dập. ...

Điều kiện tiên quyết: Đây là Phần 2 của Khóa Học System Design. Hãy đọc Phần 1: Tư Duy System Design trước để nắm vững các khuôn rập đánh đổi (trade-off frameworks) nền tảng. Answer-first: Cân bằng tải L4 (L4 load balancing) định tuyến traffic dựa trên dữ liệu siêu dữ liệu tầng giao vận (transport-layer) (IP/TCP/UDP) — chi phí CPU cực kỳ bèo bọt (minimal CPU overhead) nhưng độ thông minh thì hạn hẹp. Cân bằng tải L7 (L7 load balancing) thì xoi mói vào các headers, paths, và cookies của HTTP — cho phép định tuyến dựa trên nội dung (content-based routing) và rà soát sức khỏe cấp cao, bù lại phải trả giá bằng chi phí xử lý cao hơn cho từng cái request (higher processing overhead per request). ...

Điều kiện tiên quyết: Đây là Phần 1 của series Khóa Học System Design. Bài viết giả định bạn đã nắm được các khái niệm cơ bản về hệ thống phân tán và cú pháp của ngôn ngữ Go. Answer-first: Cốt lõi của tư duy thiết kế hệ thống vững chắc (Sound system design thinking) chính là việc cân đo đong đếm và lựa chọn các sự đánh đổi (trade-offs) xoay quanh hiệu năng (performance), độ tin cậy (reliability), và chi phí (cost). Làm quái gì có hệ thống nào hoàn hảo — mấy ông Kiến trúc sư (architects) sinh ra là để tối ưu hóa dựa trên những rào cản (constraints) áp đặt bởi yêu cầu kinh doanh thực tế và thực tại của công nghệ. ...

🇬🇧 Read the English version of this article on tanhdev.com Chào mừng trở lại với bản tin Tech Radar. Tuần trước chúng ta đã mổ xẻ cách Kratos và Dapr v1.15 giải quyết Xung đột Trạng thái qua ETags. Tuần này chúng ta sẽ đi sâu hơn một tầng: làm thế nào để cấu trúc toàn bộ codebase sao cho Kratos, Wire, và Dapr Pub/Sub kết hợp một cách gọn gàng — và làm thế nào để giữ cho kiến trúc đó dễ test, bền bỉ và an toàn trên môi trường production? ...