Nguồn: agwa.name (via Hacker News) Tóm tắt Tác giả Andrew Ayer lập luận rằng FastCGI — giao thức ra đời năm 1996 — vẫn là lựa chọn tốt hơn HTTP cho communication giữa reverse proxy và backend. Vấn đề cốt lõi của HTTP/1.1 là không có explicit framing: message tự mô tả điểm kết thúc của nó theo nhiều cách khác nhau với vô số edge cases, dẫn đến HTTP desync attacks (request smuggling)....
Nguồn: Salesforce Developer Blog Tóm tắt Salesforce vừa ra mắt tính năng Database Insights trong Scale Center — một công cụ phân tích hiệu năng SOQL theo hướng bottom-up thay vì top-down truyền thống. Trong khi các công cụ cũ chỉ phân tích static metadata của Apex code, Database Insights bắt đầu từ nơi thực sự xảy ra vấn đề: tầng cơ sở dữ liệu. Vấn đề cốt lõi được gọi là “runtime reality gap” — các scanner tĩnh không thể biết giá trị thực của bind variable trong SOQL dynamic, dẫn đến không phân biệt được giữa “selective success” (query dùng index để truy vấn đúng 10 records từ hàng triệu) và “table-scan terror” (database phải scan toàn bộ bảng vì không dùng được index)....
Nguồn: Bytebytego Tóm tắt DoorDash đã giải quyết bài toán mở rộng quốc tế bằng cách tái kiến trúc hệ thống onboarding Dasher từ một mớ if/else theo từng quốc gia thành một nền tảng module hóa. Trước đây, việc thêm một thị trường mới tốn hàng tháng kỹ thuật vì logic quốc gia nằm rải rác khắp codebase với ba phiên bản API tồn tại song song, trong đó V3 vẫn gọi xuống V2 handler và ghi vào V2 database tables....
Nguồn: Google Developers Blog Tóm tắt Google’s AI Agent Clinic đã phân tích và tái kiến trúc “Titanium” — một sales research agent hoạt động được trong môi trường dev nhưng không đáp ứng được yêu cầu production. Monolith ban đầu chạy một vòng for tuyến tính: khi một sub-task thất bại (API timeout hoặc hallucination), toàn bộ quy trình dừng mà không báo lỗi. Giải pháp là tách thành pipeline dùng Google Agent Development Kit (ADK) với các specialized sub-agents: Company Researcher, Search Planner, Case Study Researcher, Selector, Email Drafter....
Nguồn: PlanetScale Blog Tóm tắt Bài viết từ PlanetScale phân tích ba chiến lược phổ biến cho multi-tenancy trong Postgres: shared-schema (chia sẻ bảng, phân tách bằng cột tenant_id), schema-per-tenant (mỗi tenant có schema riêng), và database-per-tenant (mỗi tenant có logical database riêng). PlanetScale khuyến nghị rõ ràng shared-schema là phương pháp mặc định và là cách duy nhất đạt multi-tenancy thực sự — hai phương pháp còn lại chỉ chia sẻ tài nguyên, không chia sẻ bảng....
Nguồn: Pinterest Engineering Tóm tắt Pinterest xử lý hàng triệu URL từ các merchant domain mỗi ngày, trong đó cùng một trang sản phẩm có thể xuất hiện dưới hàng chục biến thể URL khác nhau — với tracking parameter, session token, hay analytics tag khác nhau. Bài toán deduplication đòi hỏi một hệ thống chuẩn hóa URL đủ chính xác để nhận diện nội dung giống nhau dù URL có khác biệt....
Nguồn: Salesforce Engineering Tóm tắt Nhóm kỹ thuật Salesforce đã xây dựng Agentforce Lead Nurturing Agents — một hệ thống agent tự trị chuyển đổi Sales Cloud từ một hệ thống lưu trữ dữ liệu thụ động thành một engine hành động chủ động. Hệ thống này đã tạo ra hơn 100 triệu USD pipeline, hơn 10.000 cơ hội bán hàng, và đóng góp vào 1.500 deal đã chốt thông qua automated workflow....
Nguồn: Stripe Engineering Blog Tóm tắt Bài viết này là hành trình 10 năm thiết kế API thanh toán của Stripe — từ những dòng curl đơn giản ban đầu đến hệ thống PaymentIntents phức tạp hỗ trợ đa phương thức và xác thực 3D Secure. Điểm khởi đầu là API Charge ra mắt năm 2011, chỉ cần khoảng 7 dòng curl để tạo một giao dịch thẻ tín dụng thành công — điều này trở thành một meme văn hóa của Stripe....
Nguồn: github.com/NikolayS/pgque Tóm tắt PgQue là một message queue được xây dựng hoàn toàn trong PostgreSQL, thiết kế theo triết lý “zero-bloat”: chỉ cần một SQL file để cài đặt, sử dụng pg_cron để trigger tick thay vì một daemon riêng biệt. Dự án hướng tới các team muốn có job queue mà không muốn vận hành thêm infrastructure (Redis, RabbitMQ, SQS). Thiết kế dựa trên SKIP LOCKED — tính năng của PostgreSQL cho phép nhiều worker consume messages song song mà không bị block lẫn nhau....
Nguồn: Snap Engineering Tóm tắt Snap Engineering đã chia sẻ kiến trúc backend của Spectacles — kính AR thế hệ mới của Snap — được xây dựng trên nền tảng Supabase. Quyết định sử dụng Supabase (một nền tảng backend-as-a-service dựa trên PostgreSQL) cho phép đội ngũ tập trung vào phát triển tính năng phần cứng và phần mềm đặc thù, thay vì xây dựng hạ tầng từ đầu. Snap Cloud phục vụ các tính năng cốt lõi như đồng bộ dữ liệu user, lưu trữ ứng dụng AR, và quản lý trạng thái thiết bị....
Nguồn: DB Pro Blog Tóm tắt Bài viết từ đội ngũ DB Pro đặt ra câu hỏi thực dụng: khi nào thì thực sự cần database? Luận điểm xuất phát từ một sự thật cơ bản — database cũng chỉ là files. SQLite là một file duy nhất, PostgreSQL là một thư mục files với process đứng trước nó. Vì vậy câu hỏi không phải là “dùng files hay không” mà là “dùng files của database hay files của chính mình”....
Nguồn: Databricks Blog Tóm tắt Bài viết từ Databricks trình bày kiến trúc end-to-end của hệ thống product search real-time, lấy ví dụ từ marketplace bán ô tô — nơi trong mili-giây phải trả về kết quả phù hợp ngân sách, vị trí địa lý, sở thích người dùng và mức độ liên quan. Đây không phải là lookup đơn giản mà là “real-time decision engine” cân bằng giữa revenue, click-through rate, latency và relevance....
Nguồn: Bytebytego Tóm tắt (Không thể truy cập nội dung đầy đủ — bài viết yêu cầu đăng ký trả phí trên Bytebytego) Bài viết phân tích kiến trúc AI của LinkedIn Feed — hệ thống phục vụ hơn 1.3 tỷ người dùng — và cách LinkedIn tích hợp LLM vào pipeline recommendation để cải thiện độ liên quan của nội dung hiển thị. Đây là chủ đề quan trọng trong distributed systems và large-scale ML inference....
Nguồn: PlanetScale Blog Tóm tắt B-tree là cấu trúc dữ liệu cân bằng tự động, được sử dụng rộng rãi để triển khai index trong database. Mỗi node của B-tree chứa keys và values: node gốc và node nội bộ dùng để dẫn đường tìm kiếm, còn node lá chứa con trỏ đến dữ liệu thực. Tính chất tự cân bằng đảm bảo độ phức tạp tìm kiếm luôn là O(log n)....