Golang

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. ...

Hệ thống tìm kiếm là trái tim của mọi nền tảng thương mại điện tử. Nếu khách hàng không thể tìm thấy sản phẩm, họ sẽ không mua nó. Trong một thập kỷ qua, khi nói đến Search, mặc định chúng ta nói về Elasticsearch (với thuật toán BM25). Tuy nhiên, khi hành vi tìm kiếm của người dùng thay đổi—từ việc gõ những từ khóa cộc lốc (“giày chạy bộ nam”) sang những câu lệnh dài, chứa đầy ý định phức tạp (“tìm cho tôi một đôi giày chạy trail chống nước, size 42, dưới 2 triệu, có thể giao hàng trong hôm nay”), các cỗ máy tìm kiếm truyền thống bắt đầu bộc lộ tử huyệt. ...

Bất kỳ đội ngũ kỹ thuật nào xây dựng hệ thống nghiêm túc trên Magento cuối cùng cũng sẽ đụng phải ba bức tường giống nhau: bức tường bản quyền, bức tường khả năng chịu tải (scaling), và bức tường tốc độ phát triển (developer velocity). Câu hỏi chỉ là bạn sẽ đụng phải chúng trước hay sau khi chúng bào mòn tiền bạc và khách hàng thực sự của bạn. ...

Nếu bạn đã từng thử đưa một hệ thống RAG hoặc Multi-Agent viết bằng Python (sử dụng LangChain hay AutoGen) lên môi trường Production với hàng ngàn request đồng thời, chắc hẳn bạn đã nếm mùi đau khổ. Máy chủ cạn kiệt RAM, CPU nghẽn cổ chai, và độ trễ (latency) nhảy vọt một cách không kiểm soát. Nguyên nhân không nằm ở các mô hình LLM. Nguyên nhân nằm ở chính kiến trúc điều phối (Orchestration Architecture) mà bạn đang sử dụng. ...

Bất kỳ team Magento nào khi quyết định chuyển dịch sang microservices cũng đều phải đối mặt với cùng một câu hỏi đầu tiên: cần bao nhiêu service? Ngành công nghiệp thường bảo là 4–6. “Service danh mục (Catalog), service đơn hàng (Order), service khách hàng (Customer), service tồn kho (Inventory), service thanh toán (Payment), và có thể thêm CMS nữa.” Mọi bài blog, mọi bài diễn thuyết ở hội thảo đều tựu trung ở danh sách này. Đó là một điểm khởi đầu hợp lý — nhưng nó hoàn toàn sai lầm khi áp dụng cho e-commerce nghiêm túc ở quy mô lớn. ...

Trong Phần 1: The Paradigm Shift - Kiến Trúc Agentic & Sức Mạnh Điều Phối Của Golang, chúng ta đã thiết lập bộ não điều phối (Orchestration Engine) bằng Golang và Eino. Tuy nhiên, một bộ não thông minh đến đâu cũng sẽ trở nên vô dụng nếu nó được tiếp nạp thông tin sai lệch, thiếu cấu trúc hoặc bị cắt vụn. Trong bài toán e-commerce, dữ liệu catalog sản phẩm thay đổi liên tục từng giây: giá cả biến động, tồn kho cập nhật, sản phẩm mới được thêm vào. Đồng thời, việc chia nhỏ (chunking) dữ liệu sản phẩm để đưa vào Vector Database (Qdrant) hoàn toàn khác biệt so với việc chia nhỏ một tài liệu PDF hay một bài báo. ...

Khi bạn sở hữu 21 Go microservices và 2 ứng dụng frontend, câu hỏi hạ tầng đầu tiên không phải là Kubernetes hay CI/CD — mà là làm thế nào để bạn quản lý chính bản thân phần source code? Hai lựa chọn sau sẽ thất bại ngay lập tức: polyrepo (hơn 21 repo Git rời rạc, bất khả thi để duy trì phiên bản đồng nhất) và một monorepo ngây ngô (vứt tất tần tật mọi thứ vào chung một thư mục, dependency ma ám ngập tràn). Bạn cần một công cụ quản lý monorepo thực thụ. ...

Trong Phần 2: Data Ingestion & E-commerce Chunking - Đưa Dữ Liệu Sản Phẩm Vào Môi Trường AI, chúng ta đã thiết lập một pipeline đồng bộ dữ liệu sạch sẽ từ PostgreSQL sang Qdrant qua Kafka CDC. Nhưng hành trình xây dựng một hệ thống tìm kiếm chuẩn e-commerce chỉ mới bắt đầu. Khi người dùng nhập: “laptop Asus ROG Zephyrus G14 giá dưới 30 triệu còn hàng” Nếu sử dụng Dense Vector Search thuần túy: Hệ thống có thể trả về các laptop Asus ROG Zephyrus khác nhưng giá 45 triệu, hoặc thậm chí máy cũ đã hết hàng, vì mô hình Embedding chỉ hiểu được độ tương đồng ngữ nghĩa chung chung chứ không xử lý được các phép so sánh số học cứng (Hard Filters như price < 30,000,000 và in_stock = true). Nếu sử dụng Lexical Search (BM25) thuần túy: Hệ thống sẽ thất bại khi người dùng tìm kiếm theo ý định như “máy tính chơi game mỏng nhẹ hiệu năng cao”, vì các từ khóa này không xuất hiện trực tiếp trong văn bản mô tả sản phẩm. Giải pháp tối ưu cho e-commerce là Hybrid Search — kết hợp Dense Search (hiểu ngữ nghĩa), Sparse Search/BM25 (khớp từ khóa chính xác, mã SKU) và Filterable HNSW (lọc thuộc tính cứng hiệu năng cao). ...

Đối với các kỹ sư chuyển từ Magento PHP sang, việc chuyển dịch sang Go microservices không chỉ đơn thuần là đổi ngôn ngữ lập trình — mà nó là một cách thức tổ chức code khác biệt về mặt bản chất. Magento có controller, model, block, helper, và plugin. Còn Go với Kratos v2 sở hữu chính xác 5 lớp (layer), mỗi lớp mang một trách nhiệm được định nghĩa rạch ròi. ...

Trong Phần 3: Làm Chủ Qdrant Hybrid Search - Giải Bài Toán Semantic và Hard Filters, chúng ta đã xây dựng thành công một engine tìm kiếm Hybrid mạnh mẽ, kết hợp giữa Dense Semantic và Sparse Lexical Search. Tuy nhiên, một hệ thống tìm kiếm e-commerce thực chiến không chỉ đơn thuần là việc lấy ra các văn bản tĩnh từ cơ sở dữ liệu vector. Ví dụ, người dùng hỏi: “Tôi muốn mua tủ lạnh Samsung Inverter 400L có sẵn tại chi nhánh Quận 1 và đang được áp dụng khuyến mãi.” Nếu chỉ dựa vào Vector Database, chúng ta sẽ gặp hai lỗi nghiêm trạng: ...

Mọi API hướng ra công chúng (public-facing) trong Nền tảng Composable Commerce đều bắt đầu từ một file .proto. Phần code — bao gồm các hàm handler gRPC viết bằng Go, TypeScript SDK, các route HTTP, kiểm tra tính hợp lệ của request (request validation), các mã lỗi — tất cả đều được tự động generate ra từ bản hợp đồng (contract) đó. Bài viết này sẽ ghi chép lại những quy ước đằng sau để hệ thống đó vận hành mượt mà. ...

Trong Phần 4: Active RAG & Strict Tool Calling - Kết Nối LLM Với Real-time Inventory API, chúng ta đã xây dựng thành công một đồ thị ReAct tuần hoàn để cho phép LLM gọi các API kiểm tra tồn kho và lấy thông tin khuyến mãi theo thời gian thực. Tuy nhiên, trong môi trường sản xuất thực tế, việc LLM có quyền truy cập vào các công cụ (Tools) vẫn chưa đủ để đảm bảo độ chính xác tuyệt đối. ...

Trong Phần 5: The Self-Reflection Critique Loop - Kỹ Thuật Ngăn Chặn Hallucination, chúng ta đã xây dựng thành công bộ kiểm duyệt câu trả lời tự động để đảm bảo độ chính xác logic. Tuy nhiên, khi đưa hệ thống Agentic Search này lên môi trường production quy mô lớn phục vụ hàng triệu người dùng, bạn sẽ lập tức đối mặt với những thách thức vận hành thực tế: ...

Khi một khách hàng bấm nút đặt hàng trên nền tảng Composable Commerce, có tới 7 sự kiện bắt buộc phải diễn ra theo chuỗi vắt ngang qua 4 service hoàn toàn độc lập: Tạo Đơn hàng (Order created) → Duyệt Thanh toán (Payment authorized) → Giữ chỗ Tồn kho (Stock reserved) → Kích hoạt Giao nhận (Fulfillment triggered) → Bắn Thông báo (Notification sent) → Cộng Điểm thưởng (Loyalty points awarded) → Tạo Mã vận đơn (Shipping label generated). Bất kỳ mắc xích nào trong số này cũng có thể đứt. Mạng có thể rớt. Database có thể sập. Một cái cổng thanh toán (payment gateway) của bên thứ ba có thể bị timeout. ...

21 services. 24 quyết định. 3.5 tháng trời cân lên đặt xuống được ghi chép cẩn thận vào các bản Ghi nhận Quyết định Kiến trúc (Architecture Decision Records - ADR). ADR là một tài liệu ngắn gọn gọn gàng trả lời rạch ròi câu hỏi: “Tại sao chúng ta lại cắm đầu chọn phương án X trong khi hai thằng Y và Z cũng ngon lành không kém?” Nếu không có ADR, mọi tri thức kiến trúc (architectural knowledge) sẽ chỉ tồn tại mỏng manh trong đầu các kỹ sư. Lỡ ngày đẹp trời nào đó họ nộp đơn nghỉ việc, mớ tri thức đó cũng đội nón ra đi — và thế là team mới vào tiếp quản sẽ lại cặm cụi đập đi xây lại cái component y chang cái cách mà đội ngũ cũ đã từng hăm hở thử nghiệm rồi vứt sọt rác (tried and rejected). ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Khi chuyển đổi từ Magento sang Golang, bạn có ba chiến lược cơ sở dữ liệu (database): (A) Dùng chung DB (Shared DB) để tối ưu compute ngay lập tức, (B) CDC + Outbox để tách DB dần dần mà không cần đụng vào code PHP, hoặc (C) Tách biệt hoàn toàn bằng Event Bus. Phương án A là một trạng thái chuyển giao tuyệt vời nhưng lại là một trạng thái cuối cùng thảm họa. Phương án B là con đường được khuyến nghị trong ngành công nghiệp cho hầu hết các hệ thống Magento — nó cho phép Go làm chủ schema của riêng mình và làm phẳng cấu trúc EAV mà không yêu cầu PHP Magento phải phát ra dù chỉ một sự kiện nào. Phương án C chỉ khả thi khi đội ngũ Magento của bạn có thể xây dựng và duy trì một hệ thống phát hành sự kiện (event publisher) đáng tin cậy. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Trong năm 2026, Kỹ thuật Nền tảng (Platform Engineering) cho AI không còn nằm ở việc chọn đúng LLM framework. Những câu hỏi thực sự là: Ai kiểm soát chi phí token? Ai định tuyến lưu lượng truy cập thông minh đến đúng GPU pod? Trạng thái của tác nhân (agent state) đi về đâu sau một sự cố crash? Ba dự án CNCF — Envoy AI Gateway, K8s Gateway API Inference Extension, và Dapr Agents — đang hội tụ để trả lời những câu hỏi đó ở tầng cơ sở hạ tầng, giúp mã nguồn ứng dụng (application code) không phải gánh vác. ...

🇬🇧 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. ...