Software Engineer

Phỏng vấn Middle Backend Engineer tại Công ty ZP

Một buổi technical interview tập trung vào ba nhóm vấn đề rất thực tế khi làm Backend: service-to-service communication, database design và performance khi làm việc với ORM.

Điểm đáng chú ý là các câu hỏi không dừng ở việc kiểm tra ứng viên có nhớ định nghĩa hay không. Interviewer đi sâu hơn vào việc khi nào nên chọn một giải pháp, khi nào không nên chọn nó, và trade-off phía sau mỗi quyết định kỹ thuật.

1. Kafka vs gRPC: Khi nào nên dùng cái nào?

Một trong những câu hỏi chính là:

Ưu và nhược điểm của Kafka so với gRPC là gì?

Đây không đơn thuần là câu hỏi "Kafka là gì?" hay "gRPC là gì?", mà kiểm tra khả năng lựa chọn communication pattern phù hợp với bài toán.

Kafka

Kafka phù hợp với các bài toán asynchronous communication, event-driven architecture và streaming.

Một số đặc điểm nổi bật:

• Các service được decouple tốt hơn thông qua message/event.
• Message được persist và có thể được consumer đọc lại.
• Consumer group hỗ trợ scale việc xử lý message.
• Một event có thể được nhiều consumer subscribe.
• Phù hợp với event-driven architecture và các workflow không yêu cầu response ngay lập tức.
• Có thể tận dụng partition để scale và duy trì ordering trong phạm vi partition.

Tuy nhiên, Kafka cũng có những trade-off:

• Không phù hợp với mọi request-response flow.
• Communication thường có thêm broker nên không nên mặc định xem Kafka là lựa chọn cho low-latency synchronous RPC.
• Hệ thống vận hành phức tạp hơn so với một RPC trực tiếp.
• Consumer cần xử lý các vấn đề như duplicate processing, idempotency, retry và failure handling.
• Kafka persistence/replay không đồng nghĩa với việc business processing tự động đạt exactly-once semantics.

gRPC

gRPC thường phù hợp với synchronous service-to-service communication, đặc biệt khi service cần gọi một service khác và nhận response trong cùng flow.

Một số ưu điểm:

• Communication model rõ ràng theo kiểu RPC.
• Protocol Buffers cung cấp contract rõ ràng giữa client và server.
• Có code generation cho nhiều ngôn ngữ.
• Hiệu quả cho internal service-to-service communication.
• Hỗ trợ streaming bên cạnh unary request-response.
• Có thể kết hợp với timeout, retry, load balancing và các cơ chế resilience khác.

Nhược điểm là service gọi thường có dependency trực tiếp vào service được gọi, và request sẽ phụ thuộc vào availability/latency của downstream service trong synchronous flow.

Kafka vs gRPC

| Tiêu chí | Kafka | gRPC | |---|---|---| | Communication | Asynchronous messaging / event streaming | RPC | | Response | Không cần response trực tiếp | Thường cần response trong cùng request flow | | Coupling | Loosely coupled hơn | Tightly coupled hơn ở communication flow | | Persistence | Message được broker lưu giữ | Không phải message broker | | Multiple consumers | Rất phù hợp | Không phải mô hình chính | | Replay | Có thể replay message | Không phải mục tiêu chính | | Contract | Có thể dùng schema registry + Protobuf/Avro/JSON Schema | Protobuf contract + code generation | | Use case | Event-driven, async processing, streaming | Internal API, synchronous service calls |

Điểm quan trọng không phải là Kafka tốt hơn gRPC hay ngược lại.

Một cách suy nghĩ thực tế hơn là:

Đừng chọn Kafka chỉ vì hệ thống lớn. Hãy chọn Kafka khi communication pattern thực sự cần asynchronous messaging, event streaming hoặc decoupling.

Ngược lại, nếu service A cần gọi service B và cần kết quả ngay để tiếp tục xử lý request, synchronous RPC như gRPC thường phù hợp với communication pattern đó hơn.

---

2. Database Design: Một database tốt cần cân nhắc gì?

Một câu hỏi khác được đặt ra là:

Cần cân nhắc những gì để thiết kế database tốt?

Đây là dạng câu hỏi mở, vì một database design tốt phụ thuộc rất nhiều vào business requirement và workload thực tế.

2.1. Bắt đầu từ access pattern

Không nên thiết kế database chỉ dựa trên entity hoặc class trong application.

Cần hiểu trước:

• Những query nào xảy ra thường xuyên?
• Read nhiều hay write nhiều?
• Query theo field nào?
• Có pagination không?
• Có cần sort/filter không?
• Data growth dự kiến như thế nào?
• Transaction boundary nằm ở đâu?

Từ đó mới quyết định schema, index và cách lưu trữ phù hợp.

2.2. Normalization vs Denormalization

Normalization giúp giảm duplicate data và đảm bảo consistency.

Nhưng trong một số workload, denormalization có thể giúp giảm số lượng query hoặc giảm chi phí JOIN.

Trade-off cần cân nhắc:

• Storage
• Read performance
• Write complexity
• Data consistency
• Complexity khi update dữ liệu

Không có một lựa chọn luôn đúng cho mọi hệ thống.

2.3. Index

Index cần được thiết kế dựa trên query thực tế.

Cần cân nhắc:

• Query thường xuyên nhất
• Selectivity của column
• Composite index
• Thứ tự các column trong composite index
• Read/write ratio
• Chi phí storage và maintenance của index

Có quá ít index thì query có thể chậm.

Có quá nhiều index thì write cũng trở nên tốn kém hơn.

2.4. Data integrity

Cần xác định rõ:

• Primary key
• Foreign key
• Unique constraint
• NOT NULL
• Referential integrity
• Các constraint ở database hay application layer

Mục tiêu là tránh để database rơi vào trạng thái không hợp lệ khi có nhiều service hoặc nhiều application cùng thao tác dữ liệu.

2.5. Transaction

Cần xác định rõ transaction boundary.

Không phải mọi operation đều cần nằm trong một transaction lớn.

Transaction quá rộng có thể làm tăng:

• Lock contention
• Transaction duration
• Resource usage
• Khả năng xảy ra contention khi traffic tăng

2.6. Scalability và schema evolution

Khi hệ thống lớn dần, cần nghĩ đến:

• Partitioning
• Sharding
• Read replica
• Archiving
• Data retention
• Migration strategy
• Backward compatibility khi thay đổi schema

Một database design tốt không chỉ chạy được hôm nay mà còn cần có đường phát triển khi workload thay đổi.

---

3. N+1 Query Problem

Một câu hỏi kinh điển khác:

N+1 query là gì?

N+1 thường xuất hiện khi application sử dụng ORM và vô tình thực hiện thêm một query cho từng record trong một collection.

Ví dụ:

• Query 100 orders → 1 query.
• Sau đó với mỗi order lại query customer tương ứng → thêm 100 queries.

Tổng cộng:

1 + 100 = 101 queries

Đây chính là N+1 problem.

Vì sao N+1 nguy hiểm?

Khi số lượng record tăng, số lượng query cũng tăng theo.

Ví dụ:

• 10 records → 11 queries
• 100 records → 101 queries
• 10.000 records → 10.001 queries

Trong môi trường production, vấn đề có thể trở nên nghiêm trọng hơn do:

• Database connection pool bị sử dụng nhiều.
• Network round-trip tăng.
• Database CPU tăng.
• Request latency tăng.
• Throughput giảm.

Một số cách xử lý

Tùy query shape và ORM, có thể cân nhắc:

Eager loading

Load relationship ngay trong query ban đầu khi biết chắc dữ liệu cần thiết.

Batch loading

Thay vì query từng record, gom các ID lại và query theo batch, ví dụ sử dụng WHERE id IN (...).

JOIN

Nếu phù hợp với relationship và query shape, có thể lấy dữ liệu liên quan trong cùng query.

DataLoader

Đặc biệt hữu ích trong một số GraphQL/service layer để batch và cache các request lấy related data.

Quan trọng hơn: phải phát hiện được N+1

Trong production, không nên chỉ dựa vào code review.

Có thể sử dụng:

• SQL query logging
• ORM logging
• APM
• Query tracing
• Database monitoring

Một dấu hiệu đáng chú ý là một request tạo ra số lượng SQL query lớn bất thường so với lượng dữ liệu trả về.

---

4. Điều interviewer thực sự đang kiểm tra

Ba nhóm câu hỏi trên nhìn khá khác nhau, nhưng thực tế cùng kiểm tra một năng lực:

Khả năng đưa ra technical decision dựa trên trade-off.

Ở level Middle, câu trả lời không nên chỉ dừng ở:

• Kafka là message broker.
• gRPC là RPC framework.
• Index giúp query nhanh.
• N+1 là nhiều query.

Quan trọng hơn là có thể giải thích:

Vì sao chọn giải pháp này?

Khi nào không nên chọn nó?

Trade-off là gì?

Nếu workload thay đổi thì decision có thay đổi không?

Đây cũng là điểm khiến những câu hỏi tưởng như rất cơ bản trở thành câu hỏi phân loại khá tốt giữa việc biết công nghệ và biết sử dụng công nghệ trong một hệ thống thực tế.

---

Lưu ý: Phần technical deep dive trên là phần phân tích bổ sung nhằm giúp người đọc hiểu bản chất câu hỏi và bối cảnh kỹ thuật. Đây không phải transcript nguyên văn từ interviewer hoặc candidate.

Câu hỏi bạn còn nhớ

Service Communication

1. Ưu và nhược điểm của Kafka so với gRPC là gì?

Có thể đi sâu vào:

• Synchronous vs asynchronous communication
• Coupling
• Latency
• Message persistence
• Retry/replay
• Consumer groups
• Multiple consumers
• Ordering
• Reliability và idempotency
• Use case phù hợp của từng approach

Database Design

2. Khi thiết kế một database tốt, cần cân nhắc những gì?

Các khía cạnh có thể được đề cập:

• Access pattern
• Normalization vs denormalization
• Index
• Primary key / foreign key
• Data integrity
• Transaction boundary
• Scalability
• Partitioning / sharding
• Migration và schema evolution

Performance / ORM

3. N+1 query là gì?

Có thể đi sâu vào:

• Vì sao N+1 xảy ra
• Ví dụ thực tế với ORM
• Tác động đến performance
• Cách phát hiện
• Eager loading
• Batch loading
• JOIN
• DataLoader

Kết quả phỏng vấn: Chưa được chia sẻ.

Bài viết tập trung vào nội dung technical interview và các câu hỏi được ứng viên ghi nhớ lại.