Tìm kiếm
40 kết quả cho “worker”. Tìm không phân biệt dấu.
- Worker Backpressure (Part 1): How we taught our queue workers to slow down Bài tóm tắt · Canva · 2026
…ung bình — [bài gốc](https://www.canva.dev/blog/engineering/worker-backpressure-part-1-how-we-taught-our-queue-workers-to-slow-down/) Phần 1 (vì sao và thiết kế tổng quát). Phần 2…
- HRTWorker: A SharedWorker Framework Bài tóm tắt · Hudson River Trading · 2025
…h — [bài gốc](https://www.hudsonrivertrading.com/hrtbeat/hrtworker-a-sharedworker-framework/) Bối cảnh - Đội Fullstack của HRT xây bộ web app nội bộ "Ops GUIs" cho đội Run The Day…
- Redesigning Workers KV for increased availability and faster performance Bài tóm tắt · Cloudflare · 2025
…cao — [bài gốc](https://blog.cloudflare.com/rearchitecting-workers-kv-for-redundancy/) Bối cảnh - Workers KV là kho KV toàn cầu: dữ liệu lưu ở storage theo vùng, cache khắp mạng C…
- Migrating 300+ namespaces from self-hosted Temporal to Temporal Cloud Bài tóm tắt · Coinbase · 2026
…, chờ drain thành kế hoạch nhiều tuần. - Chiến lược 2, dual workers (trading, thanh toán, workflow dài): không chuyển workflow đang chạy. Worker poll cả hai cụm ; chọn cụm là quyết…
- Netflix Conductor: A microservices orchestrator Bài tóm tắt · Netflix · 2016
…p xong". - Workflow khai báo bằng JSON DSL có version (task worker và task điều khiển: fork, join, decision, sub-workflow); task definition giữ timeout, số lần retry, kiểu retry, c…
- Meet Bandaid, the Dropbox service proxy Bài tóm tắt · Dropbox · 2018
…àng đợi đầy vì khó phân biệt quá tải với traffic bùng nổ. - Worker pool cố định để khống chế concurrency tới upstream; số worker quá lớn so với số host khoẻ làm mất tác dụng gracef…
- How we scaled async workload processing at GitLab.com using Sidekiq Bài tóm tắt · GitLab · 2020
…) xử lý việc nền bằng Sidekiq trên Redis. Lịch sử: 2013 mỗi worker class một queue, không ai quản; 2016 gom theo tính năng; 2017 lại mỗi worker class một queue, gom thành nhóm real…
- Scaling your API with rate limiters Bài tóm tắt · Stripe · 2017
…20%) cho loại quan trọng, loại kia vượt 80% thì trả 503. 4. Worker utilization load shedder : lớp cuối, chỉ bật khi sự cố lớn (100 request bị chặn trong tháng). Bốn hạng: critical,…
- Building a data plane from scratch: Stripe's own high-performance distributed proxy Bài tóm tắt · Stripe · 2026
…với Envoy, theo Stripe: - Số kết nối : mô hình mỗi core một worker, mỗi worker giữ kết nối tới mọi upstream nên mỗi server nhận một kết nối cho mỗi core của mỗi client. Service hạ…
- How we rebuilt Next.js with AI in one week Bài tóm tắt · Cloudflare · 2026
…thử nghiệm chưa qua traffic lớn và dẫn khách về Cloudflare Workers; benchmark là của chính họ trên một app 33 route. Mọi nhận định là theo Cloudflare. Bối cảnh - Next.js dùng tool…
- Maxjourney: Pushing Discord's Limits with a Million+ Online Users in a Single Server Bài tóm tắt · Discord · 2023
…g chục giây, nên chỉ gửi phần thành viên relay cần. - ETS + worker process : danh sách thành viên để trong ETS (bảng bộ nhớ dùng chung giữa process), heap guild chỉ giữ tập thay đổ…
- How we built our multi-agent research system Bài tóm tắt · Anthropic · 2025
…uan trọng gửi về agent chính. Thay đổi chính - Orchestrator-worker: agent chính phân tích câu hỏi, lập chiến lược, sinh subagent song song để khám phá từng hướng, rồi tổng hợp. Khá…
- Infrastructure patterns for agentic applications Bài tóm tắt · Render · 2026
…ạo bản ghi run bền, đẩy việc vào queue, trả về run ID ngay; worker làm việc; DB ghi tiến độ; client xem trạng thái, subscribe hay nhận callback. Bẫy: queue biết có một job, không b…
- Image Processing at Zillow: Out with the Old and In with the AWS Bài tóm tắt · Zillow · 2015
…nh gốc ghi lên S3, lỗi vào hàng đợi lỗi. - Image Processor (worker Beanstalk, Python PIL): làm sạch ảnh (bỏ viền màu đơn), render trước một bộ kích thước chuẩn lên S3; báo thành cô…
- 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 đó.
- 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…
- 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ả…
- 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:
- 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.
- 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:
- 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,…
- 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.
- 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…
- 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".
- 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:
- 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…
- 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,…
- 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…
- 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:
- 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:
- 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:
- 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…
- 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…
- Hạ tầng tìm kiếm Chủ đề Thành viên
Lúc đầu, tìm kiếm là LIKE trên database hoặc một thư viện (Lucene) nhúng trong app. Khi dữ liệu và tính năng tăng, search thành một hệ có trạng thái riêng, khác database ở mấy điểm:
- 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ì…
- 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.
- 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…
- 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ó…
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- A Lightweight Distributed Architecture to Handle Thousands of Library Releases at eBay Bài tóm tắt · eBay · 2022
…hiều cha hơn (nhiều thứ đang chờ nó) được release trước, để worker không phải ngồi chờ một nút "chặn đường" được bốc ngẫu nhiên sau cùng. - Push mode (cách đầu): service trung tâm…