Scaling up your microservice testing with Apache Spark

Stripe · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Phần 1 (vì sao replay); phần 2 (cách dựng harness): Stripe 2026. Bài mô tả pattern, không nêu số liệu vận hành.

Bối cảnh

• Ví dụ xuyên suốt: service ước tính phí mạng thẻ (interchange, scheme fee) cho mỗi giao dịch. Kết quả không do một luật quyết định mà do tổ hợp luật của mạng thẻ, ngữ cảnh merchant, thuộc tính giao dịch, chương trình đủ điều kiện; mạng thẻ còn liên tục thêm phí, đổi mức, đổi điều kiện.
• Unit test kiểm từng luật, integration test kiểm vài luồng tiêu biểu, nhưng không trả lời được câu hỏi quan trọng nhất: trên phân phối traffic thật trong quá khứ, đổi một luật hay một bảng giá thì kết quả đổi ở đâu.
• Theo Stripe, câu hỏi này gấp hơn khi có code do AI hỗ trợ viết: thay đổi nhanh hơn, có thể đúng cục bộ nhưng đổi hành vi ở một góc hẹp của phân phối đầu vào.

Thay đổi chính

• Ý chính: một request handler và một phép biến đổi Spark có cùng hình dạng (nhận đầu vào, nạp trạng thái phụ, áp logic, trả kết quả). Nếu logic lõi tách khỏi transport và tác dụng phụ, có thể gọi chính logic đó từ Spark trên hàng tháng tới hàng năm đầu vào lịch sử. Kết quả là một dataset để query, join, diff.
• Ba cách dùng:
  • Regression test: chạy song song bản production và bản ứng viên trên đầu vào lịch sử, so kết quả: bao nhiêu giao dịch đổi phí, luật nào gây ra, đổi ở interchange hay scheme fee, tập trung ở mảng nào. Không phải mọi khác biệt đều là lỗi; có diff lộ ra lỗi của bản cũ.
  • What-if cho luật sắp có hiệu lực: chạy logic hiện tại và logic tương lai trên cùng lịch sử, diff hai dataset để biết merchant, loại giao dịch nào bị ảnh hưởng, trước khi luật áp dụng. Kết quả dùng được cho cả kỹ sư, đội sản phẩm, account team, lãnh đạo.
  • Golden dataset cho pull request: tập nhỏ đầu vào + đầu ra kỳ vọng (luồng phổ biến, ranh giới đủ điều kiện, các sự cố cũ), chạy trên mỗi PR, fail build khi có khác biệt ngoài dự kiến; ca sự cố mới được thêm vào nên dataset thành đặc tả sống.
• Ranh giới riêng tư: đầu vào replay chỉ giữ trường cần cho quyết định; định danh nhạy cảm được token hoá hoặc thay bằng ID test ổn định; diff, log, golden dataset không chứa PII thô, quyền truy cập và thời hạn lưu theo độ nhạy của dữ liệu gốc.
• Vị trí trong tầng test: unit (ca dựng tay) → integration (tương tác giữa hệ) → golden dataset (ví dụ mức service đã biết) → replay lịch sử (phân phối thật, gồm cả đầu vào không ai nghĩ ra).

Vì sao

• Theo Stripe, với hệ đã chạy nhiều năm, phần đuôi dài của đầu vào lịch sử có giá trị hơn mọi bộ test viết tay; Spark cho song song lớn và scale tuyến tính.

Bài học cho SWE

• Đổi câu hỏi review từ "test có qua không" sang "hành vi đổi ở đâu, bao nhiêu, có chấp nhận được không" bằng một diff định lượng.
• Với thay đổi do AI sinh, replay trên dữ liệu có hình dạng production là cách kiểm khách quan.

Liên quan

• Stripe 2026 · Stripe 2026 (cùng công ty: chọn test trước merge) · Meta 2018 · GitLab 2021 (chạy song song đường cũ và mới, so kết quả)
• Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) · CI và build ở quy mô lớn