Dapr

Giai đoạn 1 (Phase 1) là giai đoạn an toàn nhất trong toàn bộ cuộc di dời — đó là chủ ý thiết kế (by design). Sẽ không có bất kỳ thao tác ghi (write) dữ liệu nào chạm tới hệ thống microservice mới. Magento vẫn là nguồn sự thật duy nhất (source of truth) cho mọi sửa đổi dữ liệu. Việc duy nhất mà Giai đoạn 1 làm, đó là chứng minh rằng đống microservice của bạn có thể phục vụ các thao tác đọc (read) với tốc độ nhanh hơn và độ ổn định cao hơn Magento. ...

Ở Giai đoạn 1, cả hai hệ thống đều tồn tại song song nhưng chỉ có duy nhất một thằng được phép ghi dữ liệu: Magento. Sang Giai đoạn 2, cả hai hệ thống sẽ cùng thi nhau ghi dữ liệu cùng một lúc (simultaneously). Đây là giai đoạn phức tạp nhất về mặt kỹ thuật — và cũng là nơi mà phần lớn các dự án di dời tự tay làm hỏng (corrupt) dữ liệu của chính mình nếu họ không chuẩn bị sẵn một chiến lược phân xử xung đột (conflict resolution strategy) rõ ràng sòng phẳng. ...

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 Khi trào lưu Multi-Agent bùng nổ, phản xạ tự nhiên của hầu hết các Backend Engineer là: “Hãy đóng gói mỗi Agent thành một Microservice!”. Tư duy này cực kỳ hợp lý với các hệ thống Web/App truyền thống. Tuy nhiên, đối với hệ sinh thái AI Agents, kế thừa từ bài toán Agentic System Architecture, đây lại là khởi nguồn của thảm họa hiệu năng. ...

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

Dựng một cái API cùi bắp để réo gọi Graphhopper qua lệnh http.Get thì dễ ợt. Nhưng để rèn ra một cái API Gateway đẳng cấp Principal dư sức gánh còng lưng 10,000 cuốc xe nã request cùng lúc mà không đột tử, đó đích thực là một khóa masterclass về Hệ thống Phân tán (Distributed Systems). Answer-first: Graphhopper là một con service tuyến dưới (downstream service) lệ thuộc cực nặng vào CPU. Nếu cái API Golang của bạn cứ nhắm mắt hứng đạn (traffic) rồi ném tuốt luốt thẳng xuống dưới, chỉ cần Graphhopper hắt hơi sổ mũi chạy chậm lại một nhịp thôi là bầy Goroutines sẽ dồn ứ lại thành một cục máu đông, vắt kiệt sạch RAM của server và kích hoạt một cú sập dây chuyền (cascading failure). Bạn buộc phải dựng lên một phòng tuyến “Bảo Vệ Đa Lớp” (Defense in Depth) xài tới chiêu Giới hạn Đồng thời (Concurrency Bounding), Cầu dao điện (Circuit Breakers), và trò Bắn tin Bất đồng bộ (Asynchronous Pub/Sub). ...

Go microservices từ thiết kế domain đến triển khai Kubernetes — gRPC, Dapr, OpenTelemetry, và mô hình GitOps từ một dự án chuyển đổi 21-service thực tế.

🇬🇧 Read the English version of this article on tanhdev.com 1. Giới thiệu: Phá vỡ Core Banking truyền thống Trả lời nhanh: Một kiến trúc microservices ngân hàng hiện đại sẽ thay thế các sổ cái nguyên khối cũ (như T24 hoặc Flexcube) bằng cách sử dụng Go để định tuyến giao dịch với thông lượng cao. Hệ thống đạt được tính nhất quán phân tán mà không cần dùng two-phase commit (2PC) bằng cách kết hợp Event Sourcing (luồng sự kiện bất biến của sổ cái), Điều phối Saga (dùng Temporal hoặc Dapr), mẫu Transactional Outbox và ràng buộc unique của PostgreSQL để đảm bảo API luôn idempotent. ...

🇬🇧 Read the English version of this article on tanhdev.com Hầu hết các lập trình viên Go xây dựng microservices đều biết đến mẫu Choreography Saga: service A phát ra (emit) một sự kiện, service B phản ứng, service C phản ứng với B, và cứ tiếp tục như vậy. Nếu bước C thất bại, các services sẽ phát ra các sự kiện “bù trừ” (compensation) theo thứ tự ngược lại. Mẫu này hoạt động một cách mượt mà đối với các luồng đơn giản, nhưng lại phá vỡ tính hiệu quả khi số lượng bước tăng lên: việc debug một saga thất bại đòi hỏi phải lần theo dấu vết (tracing) các sự kiện qua năm topic của message broker, và việc triển khai logic bù trừ đòi hỏi mỗi service phải hiểu toàn bộ trạng thái của saga. ...

🇬🇧 Read the English version of this article on tanhdev.com Cái rãnh Tech Radar hôm nay xách tay lôi cổ ba cái architectural shifts (cú lật kiến trúc) sừng sỏ đang nổ súng nã đạn đồng loạt vắt ngang qua mớ backend, frontend, kẹp bãi infrastructure ecosystems ngay chóp năm 2026. Lướt mâm backend, cục Dapr project đã vỗ mộc stabilize (đóng đinh) cái framework Agents v1.0 nặn chuyên trị Agentic AI. Trồi lên mâm frontend, lão React Three Fiber (R3F) đã xách búa đục đẽo bưng xong cái cầu nối vắt qua WebGPU thông qua cái sạp Three Shading Language (TSL). Lặn xuống cái infrastructure layer (tầng hạ tầng), bãi release Argo CD 3.4 nhú mầm chực nổ đã tọng thêm mớ operational safety mechanisms (cơ chế an toàn vận hành) hệ “Day 2” tử huyệt cho rổ Kubernetes GitOps. ...

🇬🇧 Read the English version of this article on tanhdev.com Cái tín hiệu TechTask sừng sỏ đập vào mỏ nhất trong vỏn vẹn 24 giờ qua đéo phải là một cái quả release framework ất ơ đơn độc nào. Mà là cái cách một lố platform updates đang tông sầm vô chung một cái thông điệp chát chúa: ba cái trò lột xác commerce modernization đéo còn chọc ngoáy vô cái màn rã nát băm vằm một cái khối monolith (nguyên khối) nữa. Nó đích thị là màn cắm đầu vô operating (vận hành) cái mớ băm vằm đó làm sao đặng giữ nguyên mạng sống an toàn. ...

🇬🇧 Read the English version of this article on tanhdev.com “Hãy đập đi viết lại toàn bộ bằng Microservices.” Câu nói này thường là điềm báo cho những dự án kỹ thuật thất bại trị giá hàng triệu đô la. Khi một ứng dụng di sản (legacy) như một hệ thống thương mại điện tử Magento khổng lồ đang gánh vác toàn bộ doanh thu tài chính của một công ty, việc thực hiện một cú chuyển đổi kiểu “Big Bang” (cắt cái rụp sang hệ thống mới) thực tế là một hành động tự sát. ...

🇬🇧 Read the English version of this article on tanhdev.com Các chủ đề được lựa chọn trong luồng pipeline số 6 vẽ nên một bức tranh vô cùng mạch lạc về hướng đi của Kỹ thuật Nền tảng (Platform engineering) ở độ tuổi trưởng thành. Sau khi trích xuất và đào sâu vào các tài liệu gốc, một thông điệp chung đã xuất hiện: Những hệ thống mạnh mẽ không chỉ được định nghĩa bởi việc chúng có thể làm được gì, mà còn bởi việc chúng tiến hóa (evolve) an toàn ra sao, chúng khôi phục (recover) dễ đoán đến nhường nào, và chúng gọt bỏ được bao nhiêu “độ phức tạp vô bổ” (accidental complexity) cho các team xây dựng ứng dụng bên trên chúng. ...

🇬🇧 Read the English version of this article on tanhdev.com Việc mở rộng quy mô (scale) một nền tảng thương mại điện tử vượt qua cột mốc 10.000+ đơn hàng mỗi ngày, với mỗi đơn chứa nhiều SKU trải dài qua nhiều kho hàng biến động là lúc mà các kiến trúc ngây thơ sẽ sụp đổ. Việc đập thêm tiền nâng cấp phần cứng không còn là viên đạn bạc khi hệ thống phải đối mặt với các giao dịch phân tán (distributed transactions), điều kiện tương tranh (race conditions), và tính nhất quán cuối (eventual consistency). ...

🇬🇧 Read the English version of this article on tanhdev.com Trong bài viết trước, chúng ta đã khám phá cách việc từ bỏ kiến trúc nguyên khối (monolithic) để ưu tiên các ranh giới ngữ cảnh nghiêm ngặt của Thiết kế Hướng Domain (Domain-Driven Design - DDD) đã giúp một nền tảng thương mại điện tử có thể scale vượt mức 10.000+ đơn hàng mỗi ngày. Tuy nhiên, việc băm nát một database khổng lồ thành 20+ database Postgres hoàn toàn cách ly lại đẻ ra một vấn đề mới cực kỳ đáng sợ: Làm thế nào để chúng ta duy trì tính nhất quán dữ liệu giữa các service đã bị cắt đứt kết nối với nhau? ...

🇬🇧 Read the English version of this article on tanhdev.com Khi chuyển đổi từ một nền tảng nguyên khối (monolith) sang một hệ thống microservice phân tán, câu hỏi khó nhất không phải là “Chúng ta viết code như thế nào?” — mà là “Làm sao để các mảnh ghép di động này nói chuyện với nhau một cách an toàn, và tại sao mỗi ranh giới lại được vẽ chính xác ở vị trí đó?” ...