Dưới đây là các ý chính từ bài viết “I Optimized a Laggy Microservice and Shocked My Interviewer: Here’s What I Did” của Shanvika Devi:
1. Bắt đầu với việc “đừng hoảng” – chẩn đoán trước khi hành động
- Tình huống kể là: trong buổi phỏng vấn, tác giả được hỏi: “Một microservice của bạn chạy rất chậm, vì các gọi API bên ngoài. Bạn sẽ tối ưu như thế nào?”
- Phản ứng đầu tiên: không vội vàng, mà tập trung vào việc tìm hiểu nguyên nhân (đo đạc, log, xác định bottleneck) trước khi đề xuất giải pháp.
2. Xác định rõ nguyên nhân gây chậm
- Nguyên nhân trong ví dụ là các cuộc gọi API externals làm nghẽn microservice — tức là vấn đề không phải code nội bộ đơn thuần, mà là dependency bên ngoài, latency mạng, blocking I/O, v.v.
- Cần phân loại: gọi API nào chậm, có retry hay timeout kiểu gì, ảnh hưởng tới service chính ra sao.
3. Ưu tiên các biện pháp “không phức tạp” trước
- Thay vì ngay lập tức redesign lớn hoặc rewrite hoàn toàn, tác giả đề xuất các bước tối ưu nhanh, hiệu quả: ví dụ caching kết quả từ API, sử dụng async non-blocking calls, tăng timeout cho phép fallback, hoặc vòng retry thông minh.
- Việc này giúp giảm độ trễ trước khi thực hiện các thay đổi kiến trúc lớn hơn.
4. Tối ưu luồng gọi API và xử lý bất đồng bộ
- Nếu microservice đang “chờ” nhiều gọi ra ngoài thì có thể chuyển sang mô hình bất đồng bộ (asynchronous), xử lý đa luồng hoặc non-blocking I/O.
- Có thể batching các yêu cầu, hoặc gộp nhiều lần gọi API thành một lần lớn hơn nếu hợp lý.
- Có thể cân nhắc sử dụng circuit breaker, timeout, fallback để tránh “đóng băng” vì một cuộc gọi API chậm hoặc mất kết nối.
5. Caching và giảm thiểu gọi API ngoài
- Nếu API bên ngoài trả về dữ liệu mà không thay đổi nhanh thì nên cache kết quả, có thể tại service hoặc tại tầng khác (in-memory, distributed cache).
- Cache giúp giảm số lần gọi ra ngoài và giảm độ trễ từ network/API.
- Đồng thời cần cơ chế invalidation hợp lý (khi dữ liệu thay đổi) để không bị dữ liệu stale.
6. Giám sát, đo lường và kiểm thử lại sau tối ưu
- Sau khi ứng dụng các biện pháp, cần đo lại performance: response time, latency của API calls, throughput, error rate.
- Từ đó xác nhận rằng tối ưu thực sự có tác dụng, và không phát sinh lỗi hoặc ảnh hưởng xấu tới các chức năng khác.
7. Tư duy và giao tiếp trong phỏng vấn – cả kỹ thuật lẫn tư duy giải quyết vấn đề
- Bài viết nhấn mạnh rằng trong phỏng vấn, không chỉ là “đáp án đúng”, mà là cách bạn tiếp cận vấn đề: bạn hỏi gì, bạn xác định giả định nào, bạn ưu tiên bước nào, bạn giải thích thế nào với người phỏng vấn.
- Khi tác giả nói “tôi không nói từ sách giáo khoa, mà nói từ những vết sẹo của việc debug hệ thống thực tế” — tức là kinh nghiệm thực chiến, tư duy thực tế được đánh giá cao.
- Việc trả lời rõ ràng từng bước (diagnose → quick wins → lớn hơn nếu cần) tạo ấn tượng “đúng vai trò backend developer” hơn là chỉ nói lý thuyết.
