Tìm kiếm
40 kết quả cho “Tiến hoá 16 năm”. Tìm không phân biệt dấu.
- 500 Tbps of capacity: 16 years of scaling our global network Bài tóm tắt · Cloudflare · 2026
…Cloudflare, phần lớn năng lực còn lại là "ngân sách DDoS" . Tiến hoá chính - Mở rộng từng thành phố: Chicago, Ashburn, San Jose, Amsterdam, Tokyo... Mỗi nơi là hợp đồng colocation,…
- 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…
- Mã hoá đầu cuối và hệ thống mà server không được đọc Chủ đề Thành viên
Một hệ thống bình thường giả định server thấy hết dữ liệu: server fan-out tin nhắn, lưu bản sao lưu, đồng bộ thiết bị, thu log để vận hành, chạy model, chống lạm dụng. Khi sản phẩm hứa chính nhà vận hành cũng không đọc…
- Stack Overflow: How We Do Deployment - 2016 Edition Bài tóm tắt · Stack Overflow · 2016
…ESS bằng Node chạy song song) → dump chuỗi C → import chuỗi tiếng Anh → deploy → webhook báo chuỗi mới. Tier meta và production chỉ chạy một phần các bước. - Deploy một web server:…
- Taking PHP Seriously Bài tóm tắt · Slack · 2016
…chạy và vòng lặp phát triển , không chỉ theo cú pháp. - Cải tiến dần thay vì viết lại: gradual typing cho phép nâng chất lượng codebase lớn mà không phải dừng lại. - Mô hình "mỗi r…
- The Stack That Helped Medium Drive 2.6 Millennia of Reading Time Bài tóm tắt · Medium · 2016
…(variants) cho A/B test và che tính năng dở. Vì sao - Stack tiến hoá theo vấn đề cụ thể (event loop bị chặn, khoá nóng, cần truy vấn linh hoạt, cần đồ thị) chứ không thay toàn bộ.…
- AWS Lessons Learned for Data Processing Pipelines Bài tóm tắt · Expedia · 2016
…ử lý tệ nhất, hoặc gia hạn theo message (). - Database tính tiền theo capacity đặt trước hợp tải đều; tải đột biến không đoán được độ lớn thì chọn hệ khác hoặc mô hình tính tiền kh…
- 5-year Evolution of Ele.me's Transaction System - Part 1 Bài tóm tắt · Ele.me · 2020
…y. Module đơn hàng EOS (Ele.me Order Service) có commit đầu tiên ngày 1/9/2012. - 5/2015: lập team đơn hàng chỉ 4 người. Tháng đầu họ xin CTO cho không nhận yêu cầu nghiệp vụ để đọ…
- Cook: A Fair Preemptive Resource Scheduler for Compute Clusters Bài tóm tắt · Two Sigma · 2016
…u, vì chia sẻ hiệu quả hơn cấp tĩnh. Có hai loại job, giống tiến trình foreground/background của OS: interactive (task nhỏ, người dùng chờ kết quả ngay; cần latency thấp) và batch…
- Building a dynamic and responsive Pinterest Bài tóm tắt · Pinterest · 2018
…llower, điểm, Pin) vào HBase. Khi user vào, quét HBase theo tiền tố user id. Thay đổi chính Xây 9 hệ thống mới để chuyển sang sinh nội dung lúc đọc (dynamic): - Following feed mới:…
- A Decade of Evolution of Alibaba's Databases - Part 1 Bài tóm tắt · Alibaba · 2019
Double 11 tạo ra một đỉnh tải cực lớn đúng 00:00, và chính đỉnh đó định hướng công nghệ database của Alibaba suốt một thập kỷ.
- 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.
- 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".
- 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ả…
- 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.
- Zero Sum by Design: 10 Years of Uber's Payments Platform Bài tóm tắt · Uber · 2026
…hỗ hằng năm của Uber từ 50 lên 217 tỉ USD; nền tảng vừa thu tiền khách vừa trả tiền cho tài xế, courier, merchant (tổng dòng tiền gần gấp đôi giá trị đặt chỗ) và giữ số dư sổ cái c…
- 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…
- 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…
- Độ 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.
- 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:
- 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…
- 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:
- 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.
- 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:
- 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…
- The million dollar engineering problem Bài tóm tắt · Segment · 2017
…ó thể từ một khách duy nhất. - Cloud dễ tới mức phản xạ đầu tiên với mọi vấn đề là chi thêm tiền. Thay đổi chính Dự án "benjamin", 3 tháng, giảm hơn 1 triệu USD/năm . - Đọc hoá đơn…
- Building High Throughput Payment Account Processing Bài tóm tắt · Uber · 2026
…250 ms (giới hạn mềm 1 giây cho thao tác real-time như giữ tiền thẻ). Đã loại: batch qua Kafka (trễ phía client và consumer 1–2 giây là bình thường), stream có thứ tự toàn cục (qu…
- The great adventure of migrating Allegro infrastructure to new Data Center - DC5 Bài tóm tắt · Allegro · 2016
…ure.html) Bối cảnh - DC2 ở Poznań là data center "thật" đầu tiên của Allegro (từ 2007). Đến 2014 có khoảng 2.000 thiết bị trong 90 tủ rack, phục vụ allegro.pl và các site khác của…
- 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:
- Zero-Growth Stack, Real Gains: How Stack Allocation Can Save 10% CPU in Go Bài tóm tắt · Uber · 2026
…có copystack , và với mỗi hàm trong trace đọc lệnh sub đầu tiên trong mã máy (dò bằng thư viện disassemble trên binary có debug symbol) để biết hàm đó dành bao nhiêu stack; cộng t…
- Netflix Billing Migration to AWS — Part III Bài tóm tắt · Netflix · 2016
…ex trong MySQL đơn luồng, còn GoldenGate load song song; số tiến trình load bằng số core. Mất khoảng 2 tuần để nạp 10 TB và cho load gia tăng đuổi kịp. Vì sao - Theo Netflix: datab…
- Lessons Learned From Scaling Uber To 2000 Engineers, 1000 Services, And 8000 Git Repositories Bài tóm tắt · Uber · 2016
…gười thắng lấy hết", nên phải lớn nhanh. - Lịch sử: bản đầu tiên được thuê ngoài viết; dispatch viết bằng Node.js (đang chuyển sang Go); core viết bằng Python (đang chuyển sang Go)…
- 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.
- Netflix Billing Migration to AWS Bài tóm tắt · Netflix · 2016
…kế hoạch toàn cầu; billing là "mạch sống tài chính" nên ưu tiên đường đi an toàn, chia nhỏ hơn tốc độ. Bài học cho SWE - Nhìn lại, Netflix nói họ đánh giá thấp nhu cầu test tự độn…
- Scaling to exabytes and beyond (Magic Pocket) Bài tóm tắt · Dropbox · 2016
…vẫn giữ backup thêm 6 tháng cho chắc. - 27/2/2015: lần đầu tiên lưu và phục vụ file hoàn toàn in-house. Mục tiêu tiếp: hơn 500 PB trong 6 tháng. - "BASE Jump" (từ 30/4/2015): lắp…
- Apache Spark Resource Optimization: Lessons From Eight Million Jobs a Day Bài tóm tắt · Salesforce · 2026
…phạm vi workload và môi trường; stage chạy lại là việc tốn tiền thêm nhưng không phải việc logic mới; memory spill và disk spill là hai biểu hiện của cùng một áp lực, cộng lại là…
- 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,…
- Đổ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.
- 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.