Tìm kiếm
40 kết quả cho “Hot ref”. Tìm không phân biệt dấu.
- 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:
- Building Git infrastructure for agent-scale development Bài tóm tắt · GitHub · 2026
…đẩy phần còn lại ra song song. - Một ref nhận mọi merge là hot key của thời agent; phân bố tải giữa các repo cực kỳ lệch (). - Việc bảo trì nặng (nén, GC) không nên chạy trên máy…
- Migrating millions of lines of code to TypeScript Bài tóm tắt · Stripe · 2022
…Jest, Webpack, Metro), chỉ sinh .tsx để sửa hàng loạt snapshot Jest; tắt tạm vài rule ESLint viết cho parser Flow. Đội sản phẩm test tay vì end-to-end test ít (bắt được lỗi bản dị…
- Building a Faster C# Driver for ScyllaDB…on our Self-Baked C#-Rust FFI Framework Bài tóm tắt · ScyllaDB · 2026
…tượng Host toàn cục và tự đếm tham chiếu kiểu Arc cho snapshot native, vì GC chỉ thấy một wrapper nhỏ chứ không thấy bộ nhớ thật phía Rust. Schema metadata trước đây nửa cache nửa…
- GoCD on Kubernetes Bài tóm tắt · Disney Hotstar · 2020
…3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://blog.hotstar.com/gocd-on-kubernetes-a4d90212d5f4) Toàn văn lấy từ bản Wayback (2021-07-15). Cùng năm với (chuyển workload lên…
- Building a New Rust Driver for ScyllaDB's DynamoDB API – with 58% More Throughput Bài tóm tắt · ScyllaDB · 2026
…AWS tăng latency mạnh, driver mới giữ thấp, nhất là p99. - Hot partition với LWT (99% request vào 10% key của một nhóm nhỏ partition): round-robin tệ hơn cả SDK AWS vì rải request…
- Instacart's Item Availability Architecture: Solving for scale and consistency Bài tóm tắt · Instacart · 2023
Điểm availability real-time từ phần 2 phải phục vụ ba nhu cầu: lấy qua RPC của team ML; lọc hàng loạt ở bước retrieval của search (RPC quá chậm); và nhất quán giữa mọi màn hình (một nơi báo hết hàng, nơi khác báo còn là…
- Stack Overflow: How We Do App Caching - 2019 Edition Bài tóm tắt · Stack Overflow · 2019
Thang độ trễ (2019): RAM khoảng 100 ns; một lần gọi Redis qua LAN của họ 0,2–0,5 ms (chậm hơn RAM 2.000–5.000 lần); trang câu hỏi render trung bình 18–20 ms, nên vài lần gọi Redis đã chiếm một phần đáng kể.
- Working with PostgreSQL Bài tóm tắt · Zerodha · 2021
…(2021). HA bằng failover replica đơn giản; backup bằng snapshot đĩa AWS. - Workload đặc biệt: 99% lượt ghi diễn ra ban đêm (quy trình EOD đối soát dữ liệu từ sở giao dịch), hàng ch…
- The feedback loops behind Kubernetes Bài tóm tắt · PlanetScale · 2026
…lượng đĩa, thao tác volume đang chờ cooldown). Gom một snapshot ở đầu vòng , mọi quyết định đọc từ đó, không hỏi lại giữa chừng (nếu không, đầu vòng thấy leader, giữa vòng thấy rep…
- Why Adaptive Warehouses Are up to 13.7x Faster for DML Operations Bài tóm tắt · Snowflake · 2026
…bất biến trên object storage đơn giản hoá đồng thời và snapshot, nhưng biến mọi thay đổi nhỏ thành ghi lớn; phải có lớp delta để chi phí ghi tỉ lệ với thay đổi thay vì với kích thư…
- Zero Sum by Design: 10 Years of Uber's Payments Platform Bài tóm tắt · Uber · 2026
…) là khái niệm của nền tảng; Freight, xe hai bánh, Transit, Hotels, thuê xe, Grocery, Ads, Memberships lên nền tảng mà lõi gần như không đổi. - Không gắn với phương thức thanh toán…
- Evolution and Scale of Uber's Delivery Search Platform Bài tóm tắt · Uber · 2026
…x: workflow train hoặc lấy model, sinh embedding, dựng snapshot index mới mà không đụng đường đọc đang chạy. - Blue/green ở mức cột của index: mỗi index có hai cột cố định embeddin…
- Real-Time Indexing for Billions of Vectors: How we built fast, fresh vector indexing at scale in CockroachDB Bài tóm tắt · Cockroach Labs · 2025
Search ngữ nghĩa quy về tìm vector gần nhau (embedding vài trăm tới vài nghìn chiều). Vector không có thứ tự tự nhiên nên index truyền thống không dùng được; ở quy mô lớn phải dùng index xấp xỉ (ANN).
- Upgrading a 56TB database that's growing at 250GB per day with (nearly) no downtime Bài tóm tắt · Trigger.dev · 2026
Một cụm Aurora Postgres khoảng 56 TB: bảng run 29,4 TB, các bảng liên quan tới run 25,4 TB, dữ liệu control plane (tổ chức, project, billing, deploy) chỉ 1,23 TB. Tăng 250 GB/ngày.
- 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:
- 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…
- 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.
- 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.
- 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:
- 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".
- 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…
- 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.
- 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.
- 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 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:
- 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…
- 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…
- 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…
- 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…
- 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ó…
- 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, độ…
- Batching và khấu hao round-trip Chủ đề Thành viên
Nhiều nút thắt không nằm ở việc mỗi thao tác tốn bao nhiêu công, mà ở chi phí cố định trả cho mỗi thao tác: một round-trip mạng, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí 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,…
- 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ỡ:
- 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.
- Geosharded Recommendations Part 3: Consistency Bài tóm tắt · Tinder · 2019
Sau khi shard theo địa lý, có hai kho dữ liệu phải khớp nhau:
- Slack Công ty Thành viên
Slack bắt đầu bằng LAMP và giữ PHP vì môi trường của nó (mỗi request trạng thái sạch, vòng lặp sửa–tải lại). Họ cải tiến dần bằng HHVM và Hack thay vì viết lại . Tầng dữ liệu đi từ MySQL active-active shard theo…
- Instacart Công ty Thành viên
Năm 2020, để bật mã hoá at-rest cho RDS Postgres vài TB mà không downtime nhiều giờ, Instacart dựng replica logic từ snapshot (đẩy vị trí replication khớp LSN của snapshot) thay vì copy toàn bộ; cách này về sau dùng cho…