Nguồn: The Payments Engineer Playbook
Tóm tắt
Uber đã viết lại hệ thống ledger (sổ cái) của mình năm lần trong vòng mười năm. Bài phân tích của Álvaro Durán chỉ ra rằng ít nhất một lần viết lại — quyết định chuyển sang DynamoDB vào năm 2017 — không những không cần thiết mà còn gây ra thiệt hại hàng triệu USD. Điều đáng lo ngại hơn: không ai bị sa thải vì quyết định này.
Vấn đề cốt lõi là DynamoDB tính phí theo từng lần đọc và ghi, trong khi mỗi chuyến xe của Uber tạo ra nhiều ledger entry. Với 15 triệu chuyến mỗi ngày, chi phí cơ sở dữ liệu bùng nổ nhanh chóng. Durán tính toán rằng Uber đã tiêu tốn khoảng $8 triệu nhiều hơn cần thiết trước khi thoát khỏi DynamoDB — và số liệu “tiết kiệm $6 triệu/năm” mà ByteByteGo và nhiều blog kỹ thuật trích dẫn thực chất là tiết kiệm so với chính mức chi phí quá cao do quyết định sai lầm gây ra.
Điểm sắc bén nhất trong bài: Uber được mời trình bày tại AWS re:Invent 2019, mô tả việc chuyển sang DynamoDB như một case study thành công — trong khi thực tế họ đang che giấu một quyết định tệ. Các kỹ sư đã tập trung vào yêu cầu kỹ thuật (scale, throughput) mà bỏ qua yếu tố kinh tế của hệ thống. Tác giả lập luận rằng mọi rewrite đều là “promotion project” của ai đó, được phê duyệt như giải pháp toàn diện, rồi dần lộ ra điểm chết người.
Bài học thực tế cho engineers: khi thiết kế bất kỳ hệ thống nào trong production, cần đánh giá đầy đủ model kinh tế — đặc biệt với database có pricing theo consumption. Kỹ sư giỏi không chỉ hiểu kỹ thuật mà còn phải hiểu tác động tài chính của từng quyết định kiến trúc.