Bài tóm tắt
Tóm tắt bằng lời riêng, luôn dẫn về bài gốc. 157 bài (đã lọc). Đọc miễn phí.
Nguồn dữ liệu danh sách bài viết của blog công ty
Danh sách bài trên trang công ty gồm 10.013 bài. Khoảng 73,6% (7.365 bài) do SWE Wiki thu thập thủ công từ kho lưu trữ blog chính chủ của các công ty, kèm ngày đăng. Phần còn lại lấy từ các danh sách công khai trên GitHub: binhnguyennus/awesome-scalability (667), abhivaikar/howtheytest (551), upgundecha/howtheysre (499), eugeneyan/applied-ml (376), Engineer1999/ML-System-Design-Case-Studies (239), upgundecha/howtheyaws (149) và một số danh sách nhỏ khác. Mọi link luôn dẫn về bài gốc trên blog của tác giả; SWE Wiki không sao chép nội dung bài. Hiện 8.979 bài thuộc 133 công ty có trang riêng được hiển thị cho thành viên. Cảm ơn những người duy trì các danh sách đó.
How Discord Stores Billions of Messages
Bản đầu của Discord được viết trong chưa tới 2 tháng (đầu 2015). Mọi thứ nằm trong một replica set MongoDB, và họ nói rõ là cố ý: làm nhanh để kiểm chứng sản phẩm, nhưng luôn chừa đường sang giải pháp bền hơn. Họ biết…
How Discord Scaled Elixir to 5,000,000 Concurrent Users
Discord dùng Elixir/Erlang VM (BEAM) từ prototype đầu tiên. Sau 2 năm: gần 5 triệu user đồng thời, hàng triệu event/giây (2017).
Postmortem of database outage of January 31
Đầu 2017, GitLab.com chạy một primary + một secondary hot standby PostgreSQL; secondary chỉ để failover, mọi tải dồn vào primary. Primary đã là điểm hỏng chung trong vài sự cố trước (bloat, polling của CI giữ khoá hàng).
Incident review: API and Dashboard outage on 10 October 2017
Dữ liệu quan trọng nhất nằm trên Postgres 3 node: primary + 1 replica đồng bộ + 1 replica bất đồng bộ (mỗi lần ghi thành công đều có ít nhất 2 bản).
Driving Southeast Asia Forward with AWS
Đây là bài nói của VP Engineering tại một sự kiện AWS, nên mang tính giới thiệu và quảng bá nhiều hơn kỹ thuật.
The million dollar engineering problem
Cuối quý 3/2016: 2/3 giá vốn (COGS) của Segment là hoá đơn AWS.
A Brief History of the UUID (KSUID)
Bài giới thiệu KSUID, thư viện Go sinh ID của Segment. Phần lớn bài là lịch sử của UUID. Bối cảnh trực tiếp: một hệ thống nội bộ dùng UUIDv4, vài tuần sau phát sinh yêu cầu sắp ID theo thời gian để lưu log lên S3 theo…
Flannel: An Application-Level Edge Cache to Make Slack Scale
Slack thiết kế cho team vài trăm người: khi khởi động, client gọi rtm.start nhận toàn bộ snapshot của team (user, channel, thành viên, tin mới nhất, DM...) rồi mở WebSocket nhận event real-time.
Maximum Warp: Building Migrations for Slack Enterprise Grid
Mô hình dữ liệu Slack: mọi dữ liệu của một team nằm trên cùng một shard MySQL, băm theo ID 64-bit của team. Dàn tải tốt, nhưng khó với dữ liệu vượt ranh giới một team.
Scaling Slack's Job Queue
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.
Secret Management Architectures: Finding the balance between security and complexity
Nhiều team để secret dạng plain text trong code hoặc file cấu hình, chỉ dựa vào việc repo là private. Slalom đề nghị tự hỏi: nhân viên nghỉ thì rotate secret có dễ không, bị lộ thì mất bao lâu để khoanh vùng, có audit…
Scaling your API with rate limiters
Thêm capacity chỉ đỡ được mấy lần tăng traffic đầu; API production còn phải chống một người dùng (vô tình hay cố ý) làm ảnh hưởng mọi người, ưu tiên request quan trọng hơn request ít quan trọng, và bỏ bớt request khi…
Kabootar — Swiggy's Communication Platform
Swiggy (giao đồ ăn, Ấn Độ) cần liên lạc với khách hàng, shipper, nhà hàng và nhân viên chăm sóc khách hàng qua push, SMS, email.
Avoid pitfalls in scaling your Cassandra cluster: lessons and remedies
Nhiều team ở Walmart dùng Cassandra làm nguồn dữ liệu chính, đọc ghi hàng chục tới hàng trăm nghìn ops/giây. Theo bài, để tới được đó họ phải "quên" nhiều mẹo của thế giới RDBMS và chấp nhận schema trông "lạ" nhưng…
Airflow at Zillow
Team Data Science and Engineering (DSE) chạy nhiều ETL; trước đó mỗi job là một service tự lên lịch riêng. Gặp Airflow năm 2016.
Save Money with EMR Auto Scaling and Spot Instances
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.
Unlocking Horizontal Scalability in Our Web Serving Tier
Monolith Rails chạy trên nhiều web server, nói chuyện với vài service Java; dữ liệu lõi trong MySQL trên RDS, đã tách database theo chức năng năm 2015.
AWS Lessons Learned for Data Processing Pipelines
Khoảng 2015, team Media Services của Expedia chuyển pipeline xử lý ảnh (nhận ảnh từ khách sạn và nhà cung cấp, tối ưu, phân phối cho các site) từ một hệ batch cũ sang pipeline dựa trên queue trên AWS.
This Rocket Ain't Stopping - Achieving Zero Downtime for Rails to Golang API Migration
Grab đang chuyển từ Rails + NodeJS sang kiến trúc service toàn Go. Một phần mục tiêu là về tổ chức: chuyển các kỹ sư Rails sang các team Go, chung một codebase.
Medium’s DynamoDB Data Source for Apache Spark
Năm 2016, dữ liệu production của Medium nằm trên DynamoDB, còn xử lý dữ liệu phía sau dùng Spark. Data warehouse cần một đường đưa dữ liệu từ DynamoDB sang Spark nhanh và tin cậy. Theo tác giả, nhiều công ty có cặp này…
The Stack That Helped Medium Drive 2.6 Millennia of Reading Time
Khoảng 25 triệu người đọc mỗi tháng, hàng chục nghìn bài mỗi tuần, tổng 1,4 tỉ phút đọc.
Ensuring Quora's Resilience to Disaster
Quora backup hằng ngày mọi kho dữ liệu gốc (MySQL, HBase, Redis, feed service) và nhân bản tới nhiều nơi.
Taking PHP Seriously
Slack viết phần lớn logic server bằng PHP. Đây là lựa chọn lạ vào năm 2016, dù Facebook, Wikipedia, WordPress, Etsy… đều thành công với nó.
Why Uber Engineering Switched from Postgres to MySQL
Kiến trúc ban đầu: monolith Python + Postgres. 2016: microservices, và phần lớn chỗ trước đây dùng Postgres giờ dùng Schemaless, một lớp sharding tự xây trên MySQL. Một số trường hợp đặc biệt dùng Cassandra.