Tìm kiếm
39 kết quả cho “test user pool”. 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
…r-our-clients-hundreds-of-versions-how-we-write-and-support-tests-php-e8fe0b79c0bc) Bối cảnh - Backend Badoo là monolith PHP 12 năm tuổi, khởi đầu không có test. Backend developer…
- 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ì…
- Load Testing Kubernetes: Building a Framework (Part 1) Bài tóm tắt · Achievers · 2023
…khó: Cơ bản — [bài gốc](https://achievers.engineering/load-testing-kubernetes-building-a-framework-part-1-bdc0af4ae7e2) Phần 1 của series; phần 2 (kết quả và các nút thắt đã gỡ):…
- March 20 ChatGPT outage: Here's what happened Bài tóm tắt · OpenAI · 2023
…Khắc phục (theo OpenAI) - Gửi bản vá cho maintainer Redis, test kỹ. - Thêm kiểm tra thừa: dữ liệu trả về từ cache phải khớp với user đang hỏi. - Quét log để chắc mỗi tin nhắn chỉ…
- Evolving Reddit's ML Model Deployment and Serving Architecture Bài tóm tắt · Reddit · 2021
Hệ ML của Reddit (2021) phục vụ hàng nghìn request inference mỗi giây cho feed, video, push, email. Inference nằm trong Minsky, một service Thrift Python (baseplate.py) vốn phục vụ dữ liệu relevance (độ giống giữa…
- Supercharging Discord Mobile: Our Journey to a Faster App Bài tóm tắt · Discord · 2025
…rên Android yếu nên quay lại FastList tự viết. Viết thêm FastestList dùng RecyclerView native và "view portaling": phía native dời view JS đã render khi vào viewport, nên biết lúc…
- Analysis of recent downtime & what we're doing to prevent future incidents Bài tóm tắt · Asana · 2019
…(sức khoẻ theo latency và số kết nối đang hoạt động); load test tới khi hỏng để tái hiện và xác nhận hệ phục hồi được. - Dài hạn: chuyển dữ liệu kiểu này khỏi RDS dùng chung sang…
- Meet Bandaid, the Dropbox service proxy Bài tóm tắt · Dropbox · 2018
…ost, có thể giữ khoảng 70% capacity khi dùng round robin. - Test tổng hợp (100.000 request, 100 worker, 10 backend) trước khi đưa lên production; loại host đã thử khi retry giảm tỉ…
- Splunk at Zillow Bài tóm tắt · Zillow · 2015
…i lần deploy làm phân bố đổi , không dùng được ở môi trường test, không tính mùa vụ. Thay đổi chính - Định nghĩa một chỉ số trải nghiệm người dùng, Factor X , gộp lỗi Apache, URL h…
- 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.
- 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.
- 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…
- 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.
- 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…
- 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…
- 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:
- 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:
- 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:
- 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.
- 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:
- Độ 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.
- Đổ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.
- 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ả…
- 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…
- 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:
- 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…
- 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".
- Bumble Công ty Thành viên
Bumble là tập đoàn hẹn hò sở hữu Badoo; bài 5/2019 trên blog bumble-tech kể cách backend PHP nguyên khối của Badoo được test khi tính năng lên server trước mọi client hàng tháng: SoftMocks cho code cũ đi kèm quy tắc…
- Upgrading a 56TB database that's growing at 250GB per day with (nearly) no downtime Bài tóm tắt · Trigger.dev · 2026
…run đi qua một "run store" (vẫn trỏ Aurora); - 4/7 chạy 358 test, không có lỗi mới; - để bắt đường code bị quên vẫn ghi vào Aurora, họ đổi credential Aurora sang tài khoản không có…
- trivago Công ty Thành viên
Service PSE-kafka đẩy giá khách sạn sang dịch vụ Ads bị consumer lag kéo dài (19 sự cố P1) dù CPU chỉ 10%. Năm 2026 một đợt điều tra tìm ra ba nút thắt cùng lúc (consumer tự viết từ 2019, độ trễ cố ý trong RAM, pool…
- Dropbox Công ty Thành viên
Dropbox luôn là hybrid: metadata ở data center riêng, nội dung file trên S3. Ở ~500 PB họ tự xây Magic Pocket, theo Dropbox vì hiệu năng và unit economics . Cái giá kèm theo là phải tự dựng cả backbone và edge network .…
- AWS CNI lessons from a Production Outage Bài tóm tắt · Neon · 2025
…AZ, tổng khoảng 12.000 IP (các region khác 24.000), vì load test cho thấy cụm chỉ cần tới 10.000 compute. Dịch vụ tăng nhanh hơn dự kiến. Diễn biến 1. 16/5: job tắt compute rảnh củ…
- How recurring network maintenance exposed 6 bugs Bài tóm tắt · Jane Street · 2026
…i nguyên không. - Thiết lập nhiều bước phải failure-atomic; test thẳng đường lỗi bằng cách ép lỗi (setrlimit, LD PRELOAD) thay vì dựng lại cả sự cố mạng. - Để giả thuyết dự đoán mộ…
- How Figma's databases team lived to tell the scale Bài tóm tắt · Figma · 2024
…, kích thước bảng, số hàng ghi) bằng dữ liệu lịch sử + load test. Kết quả: một số bảng vài TB, tỷ hàng đã quá lớn cho một DB: - vacuum của Postgres bắt đầu gây ảnh hưởng độ tin cậy…
- Evolution of our platform architecture Bài tóm tắt · Allegro · 2015
…tầng ghép service (sinh ra vai trò "Solutions Architect"), test end-to-end khó. Vì sao Theo Allegro: monolith làm mọi thay đổi rủi ro, merge khó, phản ứng chậm. Kiến trúc mới cần…
- Building High Throughput Payment Account Processing Bài tóm tắt · Uber · 2026
…tài khoản A ở hệ cũ với B ở hệ mới, phải giống hệt); stress test bằng khuếch đại traffic shadow 10–15 lần để tìm throughput tối đa, latency dưới tải cực, nghẽn ẩn (pool kết nối DB,…
- The Day Our Own Queries DoS'ed Us: Inside Zalando Search Bài tóm tắt · Zalando · 2025
…Catalog API fan-out mỗi lượt tìm thành nhiều query (có A/B test), Search API cùng các dịch vụ xếp hạng và quảng cáo. Mỗi tầng có cache riêng; coordinator node của Elasticsearch đặ…