Ba khứa kỹ sư lọt chung 1 team đang hục hặc đập chung 1 món: 1 con bot (customer support assistant) trả lời khách hàng theo cái giọng điệu nịnh nọt riêng của công ty, nhai lại ba cái thuật ngữ lấy từ cuốn bí kíp tài liệu (product documentation). Một ông gào lên “viết cụ nó 1 cái prompt xịn là xong”. Ông khác thì cự “phải mang ra mài dũa (fine-tune) lại cái mô hình”. Ông cuối phán “mù à, bài này rặt mùi RAG rồi”. ...
Bạn đã gắn các bộ thu thập đo lường cho service Go của mình với net/http/pprof, chạy thử lệnh go tool pprof cục bộ (local) kiểm tra file binary lúc dev, và đã nhìn rõ mồn một các “hot path” (đường nghẽn cổ chai tốn thời gian nhất) trên biểu đồ ngọn lửa (flame graph). Thế rồi bạn triển khai lên Kubernetes và các điểm nghẽn ấy biến mất hoàn toàn — bởi vì hồ sơ tải (workload profile) trong Kubernetes khác xa với việc test cục bộ (mix request khác nhau, áp lực pool kết nối khác nhau, hành vi GC cũng khác dưới mức chịu tải thực tế, và cả sự can thiệp từ bộ lập lịch (scheduler) của các pod nằm chung node). ...
Đại đa số các phương án triển khai RAG (Retrieval-Augmented Generation) đều mang bộ mặt giống nhau: băm tài liệu thành từng mảng nhỏ (chunk), nhồi embedding vào thành vector, quăng vào một cái cơ sở dữ liệu vector (vector database), lôi kéo trích xuất lại thông qua tương quan cosine (cosine similarity), và dồn ép cụm top-K chunk đấy vào cái context LLM. Cú đánh này rất mượt cho mấy dạng câu hỏi đáp Q&A quanh một trang văn bản cỏn con. Nhưng nó lại nát bét 1 cách rập khuôn (systematically) hễ chạm tay vào đống kho tri thức doanh nghiệp cỡ bự, nơi mà mẩu đáp án cho 1 câu hỏi ứ chịu bám dính vào độc 1 cái chunk tài liệu rời rạc, mà vắt cựa dính nhằng nhịt vào những mối dây mơ rễ má liên hệ (relationships) kết chéo chằng chịt hàng tá thực thể (entities) xuyên nhau. ...
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. ...
Ngay cái giây bạn bật cái app Uber hay Grab lên, 1 thác hệ thống thời gian thực (real-time systems) ồ ạt nổ máy cùng 1 lúc: điện thoại của bạn lăm le nhả tọa độ GPS, cái bản đồ không gian (geospatial index) xào lại vị trí của bạn, 1 cỗ máy ghép kèo (matching engine) soi lại mớ tài xế đang rảnh rỗi quanh đó, 1 mô hình tính tiền (pricing model) rặn ra cái giá mới toanh dựa trên tỷ lệ giành giật (supply-demand ratios), và 1 cái ống phụt tin nhắn (push notification pipeline) lên nòng hòng bắn cái tin chốt kèo tới tay trong vòng dưới 3 giây. ...
PayPay vừa bấm nút chạy hồi tháng 10 năm 2018 thì đã hốt trọn 10 triệu người dùng chỉ trong vỏn vẹn 3 tháng — cái đà phi mã mà chả có mống fintech Nhật Bản nào từng ngó thấy. Tới tận năm 2025, cái nền tảng này đã cán mốc 70 triệu user đăng ký và cày 7.8 tỷ lượt thanh toán mỗi năm. Chống lưng cho cú vọt mọc đó là 1 đội ngũ kỹ sư ứ những phải còng lưng bung rộng cái dàn hạ tầng của họ, mà còn phải xới tung cả cái văn hóa làm kỹ thuật: từ vụ ốp chuẩn dịch vụ (service standardization) và đẩy code kiểu GitOps (GitOps-driven deployments) cho tới trò chọc phá hệ thống (chaos engineering) và nhúng AI vô để túm bọn lừa đảo (fraud detection). ...
Điểm đúng boong 0 giờ mùa 11.11, cái rớ con nghiện Shopee tuốt tuột dải Đông Nam Á với Đài Loan đè ngón vô xào chung 1 cái nút bấm nẩy. Độc trong 10 giây nòng châm hỏa (first 10 seconds) của 1 cái mùa săn sale chớp nhoáng (flash sale), 1 cái trang quầy rác (single product page) có thể bị cả triệu mống (millions of concurrent sessions) nã liên thanh — bu xâu nhào zô giành mớ 1,000 nhúm đồ lổn nhổn nhét kho (inventory). Thẩy lố 1 cục (One oversell), đứt bóng 1 cục máy (server crash), hay cái cục kho quẹt chết lâm sàng (database deadlock) lọt chỏm ở khúc đó hất đổ 1 sớ lòi ruột đâm chọc móc tiền (cascade of chargebacks), rớ con dân nhảy đổng (angry users), dìm mặt ụp bãi cứt tờ đầu mốc nhép giang hồ bới (front-page news headlines). ...
Hễ mà bạn chốt 1 cái đơn hàng trên Amazon lúc 11:47 PM và sáng hôm sau nó lọt thỏm trước cửa nhà, thì từng li từng tí của cái hành trình đó đều bị giật dây (orchestrated) bởi một bầy thuật toán. Bọn này tự quyết định real-time chẻ ngang dọc qua cả mạng lưới ôm hàng trăm cái tổng kho (warehouses), hàng ngàn tài xế, và hàng triệu món đồ trong kho (inventory). Chả có cái khỉ gì là tình cờ (chance), và cũng ứ phải do con người tự quyết. ...
GraphHopper có lẽ là cỗ máy định tuyến (routing engine) mã nguồn mở xịn xò bậc nhất lúc này — nó nhồi đầy đủ mảng Rút Ngọn Thứ Bậc (Contraction Hierarchies - CH) cho những câu truy vấn đáp trả mượt dưới cả độ tính mili giây, nặn hồ sơ bóp nắn khuôn xe (custom vehicle profiles), khắt khe rẽ cấm góc (turn restrictions), lại kẹp nguyên bộ sậu cấu trúc hạ tầng đường sá OpenStreetMap dầy cộm. Cục sạn mà hầu hết đội nhóm cắn phải chẳng phải mảng thuật toán; nó nằm rúc ở khúc thao tác khó khăn (operational challenge) vận nó bò lết lên nổi Kubernetes: nuốt chửng một file to đùng OSM PBF vào, đẽo gọt cắt cân khối size dung lượng của JVM, xoay xở gánh qua kỳ sơ chế nhào nặn ngốn cả đóng thì giờ của mảng CH (CH pre-processing), lẫn chiêu đổi nạp dữ liệu map khỏi phải lịm tắt cúp đèn hệ thống (without downtime). ...
Xây dựng một Hệ thống Core Banking (CBS) cho một Tổ chức Tài chính Vi mô (MFI - Microfinance Institution) mang lại một tập hợp các thách thức kỹ thuật hoàn toàn khác biệt so với ngân hàng bán lẻ truyền thống. Trong khi các ngân hàng thương mại tập trung chủ yếu vào điểm tín dụng cá nhân và mạng lưới thẻ, tài chính vi mô lại vận hành dựa trên các giao dịch giá trị thấp với tần suất cao, cho vay theo nhóm (group-based lending), và thu nợ thực địa ngoại tuyến (offline field collections). ...