Tìm kiếm
40 kết quả cho “local run”. Tìm không phân biệt dấu.
- Running Kafka At Scale Bài tóm tắt · LinkedIn · 2015
…ạo nhìn thấy). - Hai tầng cụm cho multi-DC: mỗi loại có cụm local trong từng data center và cụm aggregate gom từ mọi local bằng MirrorMaker (chỉ chép local → aggregate nên không có…
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- The Legends of Runeterra CI/CD Pipeline Bài tóm tắt · Riot Games · 2021
…based: commit lỗi chặn mọi người nên vòng lặp chủ yếu ở máy local. Thay đổi chính - Nhánh phân cấp: feature branch → nhánh chung của team → main; trước đây rẽ thẳng từ main thì làm…
- Running a Software Factory Efficiently at Uber Scale Bài tóm tắt · Uber · 2026
…ở Uber (2026): hơn 70% pull request được ghi cho agent chạy local hoặc cloud; engineer đã viết hơn 3.600 agent skill , hơn 30.000 lượt chạy skill mỗi ngày. Ngày càng nhiều phiên do…
- Training Orchestrator: Unifying Model Training at Yelp Bài tóm tắt · Yelp · 2026
…runtime của cluster và trình launch job. Hệ quả: không chạy local được; khó test vì logic train lẫn với việc thực thi, mỗi thay đổi nhỏ là một vòng submit job, chờ build container,…
- From Local to Global: Building Seamless B2C Product Integration at Mercari Bài tóm tắt · Mercari · 2025
…https://engineering.mercari.com/en/blog/entry/20251009-from-local-to-global-building-seamless-b2c-product-integration-at-mercari/) Một bài trong series Global App (ngoài sheet). Bố…
- Stack Overflow: How We Do Deployment - 2016 Edition Bài tóm tắt · Stack Overflow · 2016
…eploy: thêm endpoint → chuyển consumer → dọn endpoint cũ. - Localization xử lý lúc biên dịch: chuỗi s() / m() được biên dịch thành các mảnh đã intern để giảm allocation lúc chạy. T…
- Solving Remote Build Cache Misses by Annoying Your Colleagues Bài tóm tắt · SoundCloud · 2019
…ch thì phải sắp xếp, vì thứ tự xử lý có thể khác giữa CI và local. Kết quả (theo SoundCloud) - Thời gian build trung bình từ 49,55 giây xuống 36,84 giây dù codebase lớn thêm bốn th…
- How Discord Supercharges Network Disks for Extreme Low Latency Bài tóm tắt · Discord · 2022
…g song trong DB có giới hạn, quá ngưỡng thì phải chờ đĩa. - Local SSD (NVMe) nhanh nhưng, theo Discord, kém tin cậy trong thử nghiệm của họ: hỏng đĩa hoặc host gặp sự cố là mất dữ…
- Using OxCaml to implement type-safe reference counting between OCaml and Python Bài tóm tắt · Jane Street · 2026
…l để mã hoá quyền sở hữu tham chiếu trong type: - Tham số @ local (không thoát khỏi lời gọi): glue code dựng Py.Object.t không tăng refcount, không finalizer, đặt con trỏ về NULL k…
- Safeguarding Dynamic Configuration Changes at Scale Bài tóm tắt · Airbnb · 2026
…; nền tảng sẵn sàng cao; test được trong môi trường cô lập (local, canary); mỗi tenant tự chọn trigger, guardrail, chiến lược rollout (theo AWS zone, theo phần trăm pod Kubernetes)…
- Goodbye to sequential integers, hello UUIDv7 Bài tóm tắt · Buildkite · 2023
…ngẫu nhiên nên chèn vào chỗ ngẫu nhiên trong B-tree ( index locality kém ). Sản phẩm của họ hay đọc dữ liệu mới nhất; với ID tuần tự thì dữ liệu mới nằm dồn ở mép phải của index, v…
- How LinkedIn handles merging code in high-velocity repositories Bài tóm tắt · LinkedIn · 2020
…ngay; job tự rebase và push hộ khi qua. Dev không cần HEAD local mới nhất, chấm dứt vòng lặp test → push bị từ chối → rebase ở repo bận. - Pre-merge và post-merge tuỳ repo: repo í…
- Research at scale: Orchestrating ML for systematic trading Bài tóm tắt · Optiver · 2025
…scheduler on-prem, scheduler cloud hoặc pool thread/process local. Scheduler chỉ thấy từng task; quyết định vị trí chuyển từ "cụm nào chạy cả pipeline" sang "cụm nào chạy node này"…
- Sharding Pinterest: How we scaled our MySQL fleet Bài tóm tắt · Pinterest · 2015
…oặc nâng máy. - ID 64 bit = shard ID 16 bit + type 10 bit + local ID 36 bit (auto-increment trong shard), 2 bit dự trữ: ID tự chỉ chỗ dữ liệu, không cần dịch vụ sinh ID. - Bảng obj…
- Scaling Slack's Job Queue Bài tóm tắt · Slack · 2017
Job queue chạy mọi việc không làm kịp trong request web: mỗi tin nhắn, push notification, unfurl URL, nhắc lịch, tính tiền. Ngày bận nhất hơn 1,4 tỉ job, đỉnh 33.000 job/giây.
- An AKS Performance Journey: Part 2 — Networking It Out Bài tóm tắt · ASOS · 2021
…es ban đầu; đã chạy production vài tháng. - Hướng tiếp: NodeLocal DNSCache (cache DNS trên mỗi node, nói với CoreDNS qua TCP; AKS chưa hỗ trợ vào 2/2021) và chế độ Transparent của…
- Toward a Global Identity Platform Bài tóm tắt · Mercari · 2025
…y) theo RFC 9470 ( acr values , claims ). - Ngôn ngữ qua ui locales của OIDC; app mobile dùng in-app browser để chia sẻ phiên SSO; chuẩn hoá đăng xuất theo RP-Initiated Logout. Do…
- Redesigning DuckDB's Sort, Again Bài tóm tắt · DuckDB Labs · 2025
Thiết kế 2021 () chạy tốt, nhưng từ đó hash join và hash aggregation cũng được làm cho chạy vượt RAM bằng một layout trang tràn đĩa (spillable) mới tốt hơn. Sort còn dùng cách cũ, nên bốn năm sau họ viết lại sort trên…
- Modernizing Artifact Storage at Uber Bài tóm tắt · Uber · 2026
Mọi build ở Uber (monorepo Go, Java, web, Android, iOS, Python và hàng nghìn microrepo) phụ thuộc hàng trăm tới hàng nghìn artifact. Hơn mười năm, một nền tảng artifact của bên thứ ba tự host ở hai data center nằm trên…
- Save Money with EMR Auto Scaling and Spot Instances Bài tóm tắt · Zillow · 2017
Hàng trăm job ETL batch (Spark, Hive, Sqoop) mỗi ngày, khối lượng đổi theo giờ; có lúc một mẻ tới 10 TB.
- 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…
- 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ả…
- 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…
- 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…
- 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:
- 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.
- Stream processing Chủ đề Thành viên
Khi batch hằng ngày hay hằng giờ không còn đủ tươi (chi tiêu quảng cáo phải dừng đúng lúc chạm ngân sách, dashboard MRR không được trễ 24 giờ, alert phải bắn khi contest sắp đầy), hệ phải tính liên tục trên luồng sự…
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Độ 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.
- 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…
- 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,…
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng 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.
- Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) Chủ đề Thành viên
Một quỹ định lượng hay công ty market making sống bằng vòng nghiên cứu: đặt giả thuyết → lấy dữ liệu → tạo feature → train model hay dựng tín hiệu → backtest/mô phỏng → đưa vào giao dịch thật → lặp lại. Theo Optiver, độ…
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.
- 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,…
- 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".
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi replica…