Engineering Real-Time Mobile Personalization Across iOS, Android, React Native, and Flutter

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

Bài phỏng vấn dạng hỏi–đáp (series Engineering Energizers) về một tính năng sản phẩm cho khách; số liệu duy nhất là của một khách sớm. Mọi nhận định là theo Salesforce.

Bối cảnh

• Salesforce Personalization đã cá nhân hoá web theo profile; mục tiêu là đưa sang app native mà không thành thêm một kênh tách biệt (khách xem đồ ăn Ý trên web, mở app vài giây sau mà nhận trải nghiệm chung chung).
• Sáu bài toán cùng lúc: bốn stack (iOS, Android, React Native, Flutter) khác mô hình render, vòng đời, networking, lưu trữ; ghép định danh qua web, email, mobile khi người ẩn danh đăng nhập; tránh race condition, xung đột định danh, lịch sử trùng và lưu profile thừa trên máy; chèn thành phần cá nhân hoá vào màn hình hẹp mà không phá layout, accessibility, điều hướng; quyền riêng tư, consent, mạng chập chờn, chu kỳ phát hành của store; và để marketer đổi chiến dịch mà không cần phát hành app.

Thay đổi chính

• Một mô hình cho bốn stack: schema, ngữ nghĩa sự kiện, hành vi định danh, fallback và render native thống nhất; React Native và Flutter đi qua lớp cầu gọi API native của iOS và Android, nên bề mặt SDK như nhau.
• Tách instrumentation khỏi cấu hình trải nghiệm: developer gắn app một lần: tạo placeholder ổn định (content zone, container vô hình), đăng ký thành phần native được phép (hero banner, carousel gợi ý), định nơi chúng được xuất hiện và ràng buộc bảo vệ layout. Admin tạo template hình thức và cấu trúc dùng lại; marketer tạo trải nghiệm nối template với dữ liệu real-time, targeting và content zone. Nền tảng version hoá và phát hành metadata cá nhân hoá qua CDN toàn cầu; khi app mở, SDK lấy cấu hình, áp quy tắc targeting và ánh xạ, render thành phần native phù hợp.
• Định danh và quyết định ở server: Data 360 identity resolution gộp lịch sử ẩn danh vào profile đã biết khi người dùng đăng nhập ở bất kỳ kênh nào; module mobile nằm trên SDK mobile của Data 360 (định danh, consent). SDK chỉ nhận quyết định và trải nghiệm để render, không lưu thuộc tính profile thô trên máy.
• Xem trước bằng QR: marketer chọn một trải nghiệm và một người cụ thể; trình mô phỏng nạp profile thật và sở thích real-time của người đó rồi render bằng renderer native, để kiểm targeting, nội dung, thành phần và layout mà không biên dịch lại app hay tạo dữ liệu giả.
• Kết quả, theo Salesforce: một khách sớm tích hợp trong hai tháng mà không hỏi team câu nào, và sinh hơn 150 triệu quyết định trong ba tuần.

Vì sao

• Chu kỳ phát hành của app mobile làm thay đổi nhỏ của chiến dịch thành đắt (sửa app, phát hành, chờ người dùng cập nhật), nên phần hay đổi phải nằm ngoài binary.

Bài học cho SWE

• Gắn điểm mở rộng vào app một lần, phần hay đổi (nội dung, targeting) phát qua cấu hình có version; developer giữ quyền định nơi và thành phần được phép.
• Giữ định danh và quyết định ở server, client chỉ nhận kết quả để render: ít dữ liệu nhạy cảm trên máy, ít chỗ sinh race giữa các kênh.
• Một SDK cho nhiều framework: lõi native, framework chéo đi qua lớp cầu, để hành vi giống nhau.
• Xem trước bằng dữ liệu thật của một người cụ thể thay cho dữ liệu giả.

Liên quan

• Kiến trúc frontend
• Cùng công ty: Salesforce 2026 · Salesforce 2026
• Cùng bài toán: Yelp 2026 (server-driven UI qua nhiều nền tảng) · Zerodha 2022