Tìm kiếm
40 kết quả cho “service worker”. Tìm không phân biệt dấu.
- Meet Bandaid, the Dropbox service proxy Bài tóm tắt · Dropbox · 2018
…ttps://dropbox.tech/infrastructure/meet-bandaid-the-dropbox-service-proxy) Bối cảnh - Bandaid bắt đầu là reverse proxy bù cho điểm yếu của các service phía server, rồi thành servic…
- Worker Backpressure (Part 1): How we taught our queue workers to slow down Bài tóm tắt · Canva · 2026
…khoẻ thì đó là điều mong muốn. - Khi dependency (datastore, service khác) bắt đầu lỗi, worker tham lam vẫn kéo message với tốc độ tối đa: đổ dầu vào lửa, phí tài nguyên cho message…
- 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…
- 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.
- Goodbye Microservices: From 100s of problem children to 1 superstar Bài tóm tắt · Segment · 2018
…ộ khó: Dễ — [bài gốc](https://segment.com/blog/goodbye-microservices/) Bối cảnh - Segment nhận hàng trăm nghìn event/giây và chuyển tiếp tới hơn 100 loại destination (Google Analyt…
- Business Continuity & Disaster Recovery in the Microservices world Bài tóm tắt · Walmart · 2019
…lmartlabs/business-continuity-disaster-recovery-in-the-microservices-world-ef2adca363df) Bối cảnh - Hệ Integrated Fulfilment (app và backend cho nhân viên cửa hàng soạn đơn pickup/…
- Netflix Conductor: A microservices orchestrator Bài tóm tắt · Netflix · 2016
…i gốc](https://netflixtechblog.com/netflix-conductor-a-microservices-orchestrator-2e8d4771bf40) Bài công bố mã nguồn mở Conductor. Bối cảnh - Content Platform Engineering chạy các…
- Payment Transaction Management in Microservices Bài tóm tắt · Mercari · 2019
…n/blog/entry/20210831-2019-06-07-155849/) Bối cảnh - PaymentService của Merpay (mảng thanh toán của Mercari) nằm giữa kiến trúc microservices: dùng các phương thức thanh toán ở ser…
- What it's like to work as an embedded microservices SRE Bài tóm tắt · Mercari · 2022
…mercari.com/en/blog/entry/20220228-work-as-an-embedded-microservices-sre/) Bối cảnh - Mercari có Microservices SRE Team mà thành viên được nhúng (embedded) vào từng team sản phẩm m…
- Building a data plane from scratch: Stripe's own high-performance distributed proxy Bài tóm tắt · Stripe · 2026
…cảnh - Mục tiêu độ tin cậy 99,9995% cho request thanh toán; service mesh nội bộ xử lý hàng triệu request/giây giữa hàng nghìn service (2026). Gần 10 năm dùng Envoy làm data plane.…
- Code caching for JavaScript developers Bài tóm tắt · V8 (Google) · 2019
Parse + compile JavaScript chiếm phần đáng kể thời gian khởi động trang. Code cache lưu kết quả (bytecode) để lần sau bỏ qua bước đó.
- IPVS-Based In-Cluster Load Balancing Deep Dive Bài tóm tắt · Kubernetes · 2018
…o kiến trúc. Bối cảnh - kube-proxy chạy trên mỗi node, biến Service (một IP ảo) thành việc chuyển gói tới các pod phía sau. Trước đó có hai chế độ: userspace (cũ) và iptables (mặc…
- Kabootar — Swiggy's Communication Platform Bài tóm tắt · Swiggy · 2017
…h, SMS, email. - Trước đây logic gửi nằm rải rác trong microservice của từng team. Theo Swiggy, cách đó ổn khi team nhỏ và các ca dùng tách biệt; khi scale nhanh thì cần một nền tả…
- LinkedOut: A Request-Level Failure Injection Framework Bài tóm tắt · LinkedIn · 2018
…. Bối cảnh - Mục tiêu: biết một trang xuống cấp ra sao khi service phía dưới hỏng, thử ngay trên production mà không làm member hay khách bị ảnh hưởng. Cách mịn nhất là inject lỗi…
- Migrating 300+ namespaces from self-hosted Temporal to Temporal Cloud Bài tóm tắt · Coinbase · 2026
…nhất. Thay đổi chính - Chuyển hơn 300 namespace của hơn 300 service sang Temporal Cloud; stack tự host cũ đã gỡ. Ràng buộc: không downtime có kế hoạch cho trading/thanh toán, có đư…
- Zkafka by Zillow: Go Library for Simplifying Kafka Consumption Bài tóm tắt · Zillow · 2024
…ay đổi chính - zkafka : thư viện Go mã nguồn mở, khoảng 100 service dùng; dev chỉ viết hàm xử lý một message. - Work-ahead: xử lý song song nhiều message của cùng partition, đánh d…
- Building a fault-tolerant metrics storage system at Airbnb Bài tóm tắt · Airbnb · 2026
…thời gian query dưới 30 giây . Thay đổi chính - Tenant theo service (khoảng 1.000 service ), không theo team vì quyền sở hữu team đổi thường xuyên; quy được tăng trưởng metric về t…
- Macaroons Escalated Quickly Bài tóm tắt · Fly.io · 2024
…ở Ashburn) khỏi "clearing" caveat (làm ở đâu cũng được). - Service token: worker cần secret của khách (ví dụ khoá giải mã volume) cả khi app khởi động lại hay chuyển máy, nhưng kh…
- Advancing Our Chef Infrastructure Bài tóm tắt · Slack · 2024
…Y), nay chỉ thấy node trong một stack. Chuyển sang đăng ký service vào Consul ; nhưng gọi Consul phải qua mạng overlay Nebula, mà Nebula lại do Chef cấu hình (vòng phụ thuộc), nên…
- Infrastructure patterns for agentic applications Bài tóm tắt · Render · 2026
…ator phải tất định : gọi model, đọc giờ, số ngẫu nhiên, gọi service ngoài đều phải nằm trong step. Durable execution cho biết run dừng ở đâu nhưng không thay được idempotency. Work…
- 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ả…
- 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…
- 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.
- 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:
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- 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…
- Bảo mật hạ tầng và quản lý secret Chủ đề Thành viên
Khi hệ thống lớn lên, số credential (mật khẩu DB, API key, SSH key, token, cookie phiên) tăng theo số service, pipeline, nhà cung cấp, và chúng rải vào code, cấu hình, hệ build, log. Các nguồn trong wiki cho thấy kẻ tấn…
- 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:
- Load test và kiểm chứng capacity Chủ đề Thành viên
Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì…
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- 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:
- Hạ tầng phục vụ LLM inference Chủ đề Thành viên
Phục vụ LLM giống một dịch vụ web ở chỗ cần scale theo tải, deploy phiên bản mới an toàn và phục hồi khi một process chết; nhưng ba đặc điểm làm các công cụ quen thuộc hỏng:
- Quản lý fleet và migrate code hàng loạt Chủ đề Thành viên
Khi số component (repo, service, pipeline, thư viện) tăng nhanh hơn số kỹ sư, chi phí của mỗi thay đổi xuyên suốt (nâng thư viện, vá bảo mật, đổi API nội bộ, khai tử dataset) tỉ lệ với số component chứ không với độ khó…
- 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…
- 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.
- 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,…
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- 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".
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- Sinh ID phân tán Chủ đề Thành viên
Khi chỉ có một database, AUTOINCREMENT là đủ. Khi dữ liệu nằm trên nhiều máy, ID không còn duy nhất toàn hệ thống. Đây thường là thứ đầu tiên vỡ khi phân tán dữ liệu. Yêu cầu hay gặp: duy nhất, sắp được theo thời gian,…