Mobile Architect

Lấy database cục bộ làm nguồn sự thật cho UI: UI chỉ đọc từ DB local, tầng sync lo việc đồng bộ với server.

• Lưu trữ: Room, SwiftData / Core Data, Drift hoặc Isar (Flutter). UI quan sát dữ liệu qua Flow, @Query hoặc Stream.
• Ghi khi offline: lưu thay đổi vào hàng đợi (outbox) kèm trạng thái pending; khi có mạng thì gửi lên, nhận phản hồi rồi đánh dấu đã đồng bộ.
• Lập lịch đồng bộ: WorkManager (Android), BGTaskScheduler (iOS), có ràng buộc mạng và backoff khi lỗi.
• Xung đột: chọn chiến lược như last-write-wins theo timestamp server, version number, hoặc cho người dùng chọn với dữ liệu quan trọng.
• Request cần idempotent (gửi kèm id do client sinh) để retry không tạo bản ghi trùng.

Người phỏng vấn muốn nghe: bạn tính tới đồng bộ từng phần (delta sync) và cách hiển thị trạng thái "chưa đồng bộ" cho người dùng.

Coi app là môi trường không tin cậy: mọi thứ đóng gói trong app đều có thể bị đọc, nên kiểm soát quan trọng nhất phải nằm ở server.

• Lưu token: Keychain (iOS), Keystore kết hợp EncryptedSharedPreferences hoặc DataStore mã hoá (Android), flutter_secure_storage. Không lưu trong SharedPreferences / UserDefaults thường hay log ra console.
• Phiên đăng nhập: access token ngắn hạn, refresh token xoay vòng; đăng nhập OAuth dùng PKCE.
• Mạng: chỉ HTTPS; có thể dùng certificate pinning nhưng cần kế hoạch xoay chứng chỉ.
• Secret: không nhúng API key quan trọng trong app; gọi qua backend.
• Chống can thiệp: obfuscation (R8), Play Integrity API, App Attest để server xác minh app thật.

Hay sai: tin rằng obfuscation là đủ. Nó chỉ làm chậm kẻ tấn công.

Không có đáp án chung; quyết định dựa trên yêu cầu sản phẩm, đội ngũ và chi phí dài hạn.

• Cross-platform (Flutter, React Native, hoặc Kotlin Multiplatform để chia sẻ logic): một codebase cho hai nền tảng, ra mắt nhanh, hợp với app nghiệp vụ, thương mại điện tử, nội bộ.
• Native: cần tích hợp sâu với hệ điều hành (widget, camera hoặc Bluetooth phức tạp, xử lý nền), hiệu năng đồ hoạ cao, hoặc muốn dùng tính năng mới của OS ngay khi ra mắt.

Các yếu tố cần cân nhắc:

• Kỹ năng hiện có của team và khả năng tuyển người.
• Mức độ tuỳ biến UI theo từng nền tảng.
• Chi phí viết plugin native khi thư viện không có sẵn.
• Kích thước app và thời gian khởi động.

Người phỏng vấn muốn nghe: bạn đưa ra lập luận gắn với bối cảnh cụ thể và nhắc tới phương án lai, vd. thêm màn hình Flutter vào app native.

Mỗi kỹ thuật giải một vấn đề khác nhau, nên cần xác định điểm nghẽn là đọc, ghi hay kích thước dữ liệu.

• Read replica: giảm tải đọc. Phải chấp nhận replication lag; luồng vừa ghi xong đọc lại nên đọc từ primary.
• Partitioning (trong một DB): chia bảng theo khoảng thời gian hoặc theo key. Query có điều kiện trên partition key chỉ quét phần liên quan, xoá dữ liệu cũ bằng DROP PARTITION rất nhanh.
• Sharding (nhiều DB): khi một máy không chịu nổi lượng ghi hoặc dung lượng. Đổi lại phải chọn shard key cẩn thận, query xuyên shard và transaction phân tán rất khó.

Thứ tự hợp lý: tối ưu query và index, archive dữ liệu cũ, thêm replica và cache, partition, cuối cùng mới shard.

Hay sai: chọn shard key gây hot spot, vd. theo ngày tạo khiến mọi lượt ghi dồn vào một shard.

Chia thay đổi thành nhiều bước tương thích ngược để phiên bản code cũ và mới chạy song song được (expand rồi contract).

1. Expand: thêm cột mới cho phép NULL hoặc có default; tránh câu lệnh viết lại cả bảng.
2. Code mới ghi vào cả cột cũ và mới.
3. Backfill dữ liệu cũ theo từng lô nhỏ, có nghỉ giữa các lô để không gây lag replica.
4. Chuyển code sang đọc cột mới, kiểm tra kỹ.
5. Contract: bỏ cột cũ ở một lần deploy sau.

Index trên bảng lớn: PostgreSQL dùng CREATE INDEX CONCURRENTLY; MySQL dùng online DDL hoặc công cụ như gh-ost, pt-online-schema-change.

Người phỏng vấn muốn nghe: bạn biết DDL có thể giữ lock khiến mọi query xếp hàng, nên đặt lock_timeout và luôn có kế hoạch rollback.

Quyết định kiến trúc là chọn trade-off dựa trên ràng buộc thực tế (nghiệp vụ, đội ngũ, ngân sách, thời gian), không phải chọn công nghệ "tốt nhất".

• Xác định các thuộc tính chất lượng quan trọng nhất (hiệu năng, sẵn sàng, bảo mật, chi phí, khả năng thay đổi) và sắp xếp ưu tiên cùng stakeholder.
• Đưa ra 2–3 phương án, so sánh rủi ro; làm POC hoặc spike cho điểm chưa chắc chắn.
• Ghi lại bằng ADR (Architecture Decision Record): bối cảnh, quyết định, phương án đã loại, hệ quả. Lưu cùng repo để người sau hiểu "vì sao".
• Phân biệt quyết định khó đảo ngược (chọn DB, ranh giới service) với quyết định dễ thay đổi; quyết định dễ đảo ngược thì nên làm nhanh.
• Xem lại quyết định khi bối cảnh thay đổi.

Người phỏng vấn muốn nghe: bạn thuyết phục đội ngũ bằng dữ liệu, lắng nghe phản biện, và kể được một quyết định từng sai cùng cách bạn sửa.

Coroutine là tác vụ nhẹ có thể tạm dừng (suspend) mà không chặn thread. suspend fun chỉ gọi được từ coroutine hoặc từ suspend function khác.

• Scope quyết định vòng đời: viewModelScope, lifecycleScope tự huỷ coroutine khi ViewModel hoặc màn hình bị huỷ.
• Dispatcher quyết định chạy ở đâu: Main, IO, Default.
• Structured concurrency: coroutine con gắn với cha; cha huỷ thì con huỷ, con lỗi thì lan lên cha (trừ khi dùng SupervisorJob).

viewModelScope.launch {
    val user = withContext(Dispatchers.IO) { repo.fetchUser() }
    _state.value = UiState.Success(user)
}

Hay sai: dùng GlobalScope gây rò rỉ; bắt CancellationException trong catch (e: Exception) mà không ném lại, làm hỏng cơ chế huỷ.

Swift concurrency đưa bất đồng bộ vào ngôn ngữ, cùng với kiểm tra data race lúc biên dịch (chặt hơn từ Swift 6).

• async/await: viết code bất đồng bộ tuần tự, thay cho completion handler lồng nhau.
• Task { } tạo tác vụ mới; async let và TaskGroup chạy song song có cấu trúc. Task hỗ trợ huỷ hợp tác qua Task.checkCancellation().
• actor: kiểu tham chiếu mà trạng thái bên trong chỉ được truy cập tuần tự, tránh data race. Gọi từ ngoài phải await.
• @MainActor: đảm bảo code chạy trên main thread, dùng cho ViewModel và UI.
• Sendable: đánh dấu kiểu an toàn khi chuyển giữa các vùng concurrency.

@MainActor final class ProfileViewModel: ObservableObject {
    @Published var user: User?
    func load() async { user = try? await api.fetchUser() }
}

Hay sai: actor reentrancy: sau mỗi await, trạng thái của actor có thể đã bị thay đổi.

Mục tiêu chung là tách UI khỏi logic để dễ test và dễ bảo trì.

• MVC: dễ bắt đầu nhưng trên iOS UIKit thường thành "Massive View Controller".
• MVVM: ViewModel giữ state và logic, View chỉ quan sát và hiển thị. Hợp tự nhiên với SwiftUI, Jetpack Compose (ViewModel + StateFlow) và Flutter.
• MVI / Unidirectional data flow: một state bất biến duy nhất cho màn hình, UI gửi intent, reducer tạo state mới. Dễ debug, hợp với UI khai báo.
• Clean Architecture: chia layer presentation / domain / data, repository che giấu nguồn dữ liệu (API, cache, DB).

Người phỏng vấn muốn nghe: lý do chọn kiến trúc cho dự án cụ thể. App nhỏ không cần đủ use case và mapper ở mọi tầng; app lớn nhiều team thì nên chia module theo tính năng.

Cho thấy bạn có cách làm cụ thể, không chỉ nói "em chịu được áp lực".

• Chia nhỏ việc, ưu tiên phần quan trọng nhất cho mục tiêu.
• Báo sớm cho lead/PM nếu thấy không kịp, đề xuất cắt phạm vi hoặc xin hỗ trợ.
• Giữ chất lượng ở phần cốt lõi; ghi lại nợ kỹ thuật để xử lý sau.
• Giữ bình tĩnh, giao tiếp ngắn gọn, rõ ràng với team.

Câu mẫu theo STAR: "Trước buổi demo cho khách, team phát hiện lỗi tích hợp chỉ còn hai ngày. Em liệt kê các phần bị ảnh hưởng, cùng PM chọn luồng nào bắt buộc phải chạy cho demo, phần còn lại hẹn bàn giao tuần sau. Demo diễn ra suôn sẻ và khách đồng ý với lịch mới."

Hay sai: khoe thức trắng nhiều đêm. Người phỏng vấn muốn thấy bạn quản lý được áp lực, không chỉ chịu đựng.