How Slack Rebuilt Notifications

Bài tóm tắt Slack 2026 4. Điều chỉnh Độ khó: Dễ

Slack · 2026 · 4. Điều chỉnh · Độ khó: Dễ — bài gốc

Phần lớn bài là sản phẩm/UX (thiết kế lại cài đặt thông báo); wiki chỉ giữ phần migration dữ liệu preference.

Bối cảnh

  • Thông báo là một trong ba nguyên nhân hàng đầu của ticket hỗ trợ. Hệ preference cũ tích luỹ nhiều năm: desktop và mobile có hai hệ riêng, cùng chữ mà nghĩa khác ("nothing" trên mobile khác "Off" trên desktop); "nhận thông báo về cái gì" dính chặt với "nhận bằng cách nào" (muốn ít push thì mất luôn thông báo trong app); trạng thái không đồng bộ giữa client.

Thay đổi chính

  • Mô hình mới: kênh có ba lựa chọn (mọi tin, mention, tắt), push bật/tắt riêng, cài đặt nâng cao cho người dùng chuyên sâu.
  • Migrate hàng triệu user mà không sửa dữ liệu cũ ở DB: thấy chuyển "off" thành "mentions" ở tầng DB là quá rủi ro cho tương thích ngược và rollback. Thay vào đó:
    • Thêm preference mới desktop_push_enabled, là thứ duy nhất quyết định có push trên desktop hay không. Vì nó chưa từng tồn tại nên backfill được cho mọi user dựa trên việc họ có đặt "off" hay không, không ảnh hưởng trải nghiệm hiện tại.
    • Diễn giải lúc đọc: "off" cũ được đọc như "mentions" + push tắt, đúng với hành vi thực tế của nó.
  • Bài học migration và rollback theo bài:
    • Thêm fallback lúc đọc để push_enabled: false luôn nghĩa là không push, kể cả khi rollback.
    • Một trường sai định dạng từng đặt lại preference của user về "Mentions" cho tới khi dọn dữ liệu và xả memcache.
    • Bỏ tham số "sync" ngầm, lưu giá trị desktop và mobile tường minh cho dễ đoán.
  • Kết quả (theo Slack): lượt tương tác với cài đặt tăng 5 lần và duy trì; ít user phải override từng kênh hơn; ticket giảm đáng kể.

Vì sao

  • Thêm một trường mới rồi backfill và diễn giải dữ liệu cũ lúc đọc giữ đường lui: dữ liệu cũ không bị ghi đè, rollback chỉ là đổi code đọc (Migration không downtime).

Bài học cho SWE

  • Muốn đổi nghĩa một giá trị đã lưu cho hàng triệu dòng, ưu tiên thêm trường mới + diễn giải lúc đọc thay vì viết lại tại chỗ.
  • Nhớ cache khi migrate schema: dữ liệu sai đã nằm trong cache vẫn phục vụ sau khi sửa DB.
  • Trạng thái ngầm (một cờ "sync") khó đoán hơn hai giá trị tường minh.

Liên quan