Tìm kiếm
40 kết quả cho “API client”. Tìm không phân biệt dấu.
- A monolithic architecture for our clients' hundreds of versions: how we write and support tests Bài tóm tắt · Bumble · 2019
…đúng phiên bản MySQL, và chạy song song không khoá nhau. - API test giả lập phiên client theo đúng giao thức: pool test user dùng lại và khôi phục về trạng thái lúc đăng ký sau mỗ…
- Building a New Rust Driver for ScyllaDB's DynamoDB API – with 58% More Throughput Bài tóm tắt · ScyllaDB · 2026
…lladb.com/2026/08/27/new-rust-driver-for-scylladbs-dynamodb-api/) Bài nhà cung cấp; dự án sinh viên (Đại học Warsaw) hợp tác với ScyllaDB. Benchmark do chính họ chạy trên cụm nhỏ (…
- From Event-Driven Chaos to a Blazingly Fast Serving API Bài tóm tắt · Zalando · 2025
…tps://engineering.zalando.com/posts/2025/03/event-driven-to-api.html) Bối cảnh - 2016: Zalando dựng microservices với các CRUD API riêng cho từng phần dữ liệu sản phẩm. Mỗi sản phẩ…
- How the controller-runtime Cache Actually Works, and Why Your Controller Does Not Crash the API Server Bài tóm tắt · Kubernetes · 2026
…lầm phổ biến: r.Get() / r.List() trong reconciler gọi thẳng API server và luôn thấy trạng thái mới nhất. Thực tế ngược lại. - Nếu mỗi reconcile gọi API server, hàng chục controller…
- Catching bugs on the client-side: how we developed our error tracking system Bài tóm tắt · Bumble · 2020
…trong khi team dùng PHP và Go. Tự làm Gelato . - Thu thập: API đọc, kiểm định dạng để bỏ nhiễu, rồi đẩy vào hàng đợi trung gian (LSD, Live Streaming Daemon, hệ đã dùng lâu ở Badoo…
- A deep dive into Cloudflare's September 12, 2025 dashboard and API outage Bài tóm tắt · Cloudflare · 2025
…dflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/) Bối cảnh - Tenant Service (Go, chạy trên Kubernetes ở một số data center) nằm trong logic phân quyền của mọ…
- How Netflix Scales its API with GraphQL Federation (Part 1) Bài tóm tắt · Netflix · 2020
…bài gốc](https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2) Bối cảnh - Mảng Studio (sản xuất nội dung) có hàng trăm ứng dụng; dữ li…
- Rest.li: RESTful Service Architecture at Scale Bài tóm tắt · LinkedIn · 2013
…ver type-safe, IDL mô tả resource, kiểm tra tương thích khi API đổi. - R2: lớp transport REST bất đồng bộ, hiện thực HTTP bằng Netty. - D2 (Dynamic Discovery): ZooKeeper làm regist…
- DNS fallback for better resilience Bài tóm tắt · Algolia · 2015
…nhà cung cấp chậm hơn mà không có lý do. - Họ đặt logic vào API client do chính họ viết : client dùng nhiều tên miền . algolia.net (NSONE, nhanh và thông minh) là đường chính; algo…
- Scaling your API with rate limiters Bài tóm tắt · Stripe · 2017
…cảnh - Thêm capacity chỉ đỡ được mấy lần tăng traffic đầu; API production còn phải chống một người dùng (vô tình hay cố ý) làm ảnh hưởng mọi người, ưu tiên request quan trọng hơn…
- Service Architecture at SoundCloud — Part 1: Backends for Frontends Bài tóm tắt · SoundCloud · 2021
…h - Trước 2013, SoundCloud "tự ăn món mình nấu": một Public API duy nhất phục vụ cả app chính thức lẫn bên thứ ba. - Nhu cầu scale cả vận hành lẫn tổ chức đẩy họ từ monolith sang m…
- Etsy's Journey to TypeScript Bài tóm tắt · Etsy · 2021
…), cho ngoại lệ bằng comment tắt lint từng dòng. - Kiểu cho API: API viết bằng PHP; tận dụng việc sinh OpenAPI spec của API công khai, viết bộ sinh spec cho mọi endpoint nội bộ, dù…
- Scaling Time Series Data Storage — Part II Bài tóm tắt · Netflix · 2018
…ịa cho ít nhất 5 lần tăng trưởng; tiết kiệm nhờ nén và TTL. API cũ vẫn chạy (tương thích ngược), API mới cho tập con cần client đổi, nên server và từng client migrate độc lập. Vì s…
- Accelerating Search and Ingestion with High-Performance gRPC in OpenSearch Bài tóm tắt · Uber · 2026
…Proto → đối tượng Java và gắn dịch vụ gRPC riêng. - Ưu tiên API nhạy latency nhất: Search và Bulk. - Giữ REST và Protobuf đồng bộ bằng pipeline tự động từ đặc tả OpenAPI: tiền xử l…
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Making messaging interoperability with third parties safe for users in Europe Bài tóm tắt · WhatsApp · 2024
…ạ tầng đã chịu hơn 100 tỉ tin/ngày. - Danh tính: Enlistment API khi bên thứ ba tham gia; user giữ định danh hiển thị của dịch vụ gốc và được cấp thêm một định danh nội bộ WhatsApp…
- From 48k lines of code to 10: the story of GitHub's JavaScript SDK Bài tóm tắt · GitHub · 2020
…v0.1). Năm 2017 GitHub nhận nó làm SDK chính thức cho REST API, chạy cả Node lẫn trình duyệt; lúc đó khoảng 16.000 dòng, lõi là routes.json gần 8.000 dòng viết tay định nghĩa mọi…
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Lessons learned from running GraphQL at scale Bài tóm tắt · Dream11 · 2021
…e hai tầng (server GraphQL và client) theo header X-TTL mỗi API trả về; nhờ GraphQL làm chung xác thực, biến đổi, cache nên microservice phía sau thu nhỏ được. - Vấn đề: IPL 2020 (…
- Cache made consistent: Meta's cache invalidation solution Bài tóm tắt · Meta · 2022
…t; là nguồn gốc của phần "cache invalidation và consistency API" mà chỉ nhắc lướt. Bối cảnh - Meta vận hành TAO (hơn một nghìn nghìn tỉ query mỗi ngày) và Memcache. Cache động khác…
- Taking our Ruby & Kafka stack to the next level Bài tóm tắt · Doximity · 2022
…i Kafka qua gem nội bộ dox-messaging , vốn bọc ruby-kafka : API thân thiện hơn, ép best practice, mặc định hợp với use case của họ. - Khi dùng Kafka nhiều hơn: nút thắt ở service p…
- Moving Railway's Frontend Off Next.js Bài tóm tắt · Railway · 2026
…g của Next.js ( next/image , next/head , next/router ) sang API trình duyệt hoặc thư viện trung lập, chưa đổi framework; PR 2 mới đổi framework, tách phần không phải routing khỏi f…
- Building a Data Streaming Platform Bài tóm tắt · Zillow · 2020
…h - Data Streaming Platform dạng dịch vụ: team chỉ gọi REST API ; nền tảng dùng stream bên dưới và một bảng routing lưu bền để đưa message tới đích. - Stream riêng cho mỗi ứng dụng…
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Rust at scale: An added layer of security for WhatsApp Bài tóm tắt · WhatsApp · 2026
…ng; tăng bảo đảm cho mã C/C++ còn lại (CFI, allocator cứng, API buffer an toàn, đào tạo, phân tích tự động, SLA sửa lỗi); mặc định ngôn ngữ an toàn bộ nhớ cho mã mới . Bài học cho…
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- Kiến trúc frontend Chủ đề Thành viên
Frontend bắt đầu là vài trang render ở server; lớn lên thành ứng dụng có trạng thái, nhiều team cùng sửa, và mỗi tính năng thêm vào là thêm byte phải tải. Ba trục lặp lại trong các nguồn: render ở đâu (server, client,…
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Chọn database theo workload Chủ đề Thành viên
Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…