50 câu hỏi phỏng vấn lập trình viên Backend phổ biến và câu trả lời

50 câu hỏi phỏng vấn lập trình viên Backend phổ biến và câu trả lời

Nguồn tham khảo

Chuẩn bị sẵn sàng cho một cuộc phỏng vấn đối với kĩ sư phát triển phần mềm không bao giờ là đơn giản, đặc biệt nếu như bạn là người mới làm quen với các công nghệ chính của công ty. Đó là lý do tại sao hiểu về các loại câu hỏi có thể được nhận trong một cuộc phỏng vấn kĩ thuật là chìa khóa để thành công.

Trong bài viết này , chúng ta sẽ xem xét 50 câu hỏi phỏng vấn backend phổ biến được sắp xếp theo cấp bậc kinh nghiệm.

Cho môĩ câu hỏi, chúng tôi sẽ cung cấp một vài giải thích đi kèm, nhưng đừng ngại việc nghiên cứu sâu hơn về chi tiết cho từng chủ đề, hoặc truy cập Backend nếu như bạn muốn tìm kiếm một nơi để bắt đầu hành trình học tập của mình.

Chuẩn bị cho buổi phỏng vấn Backend của mình

Trước khi bắt đầu, điều quan trọng là phải nhớ những điểm sau đây khi chuẩn bị cho cuộc phỏng vấn kỹ thuật backend của bạn:

• Đề cập đến những điều cơ bản về phát triển backend. Nếu bạn đang ứng tuyển vào vai trò phát triển web, hãy đảm bảo rằng bạn hiểu cách thức giao tiếp giữa máy khách và máy chủ hoạt động. Nếu bạn đang ứng tuyển vào phát triển công cụ phát triển, hãy hiểu các phương pháp hay nhất xung quanh phát triển CLI, v.v.
• Thực hành lập trình, bằng cách phát triển các dự án nhỏ của riêng bạn hoặc bằng cách sử dụng các trang web như LeetCode, HackerRank và các trang web khác.
• Hãy cân nhắc việc đọc về kiến trúc phần mềm; ngay cả khi vai trò của bạn không phải là kiến trúc sư, bạn sẽ thể hiện sự hiểu biết ở cấp độ cao hơn bằng cách có thể thảo luận về các chủ đề này.
• Hãy đảm bảo rằng bạn có ít nhất một sự hiểu biết cơ bản về hầu hết các lớp công cụ và thực hành cơ bản cho vai trò của mình, chẳng hạn như quản lý phiên bản (tức là sử dụng Git), thử nghiệm (ít nhất là trong thử nghiệm đơn vị), DevOps (bao gồm cả đường ống CI/CD, v.v.) và bất kỳ điều gì khác liên quan đến vai trò của bạn và công ty.
• Nói chung hơn, hãy nhớ đọc về công ty để có thể thể hiện sự quan tâm và hiểu biết về doanh nghiệp/sản phẩm của họ và cũng chuẩn bị một vài câu hỏi của riêng bạn, cho thấy bạn quan tâm đến vai trò và công ty.

Với những điều đã nói ở trên, bây giờ chúng ta hãy tập trung vào danh sách các câu hỏi phỏng vấn back-end mà bạn có thể được hỏi khi ứng tuyển vào vị trí phát triển back-end!

Danh sách câu hỏi

Beginner Level

1. Giải thích API Endpoint là gì?

   API (Application Programming Interface) Endpoint là một URL cụ thể đóng vai trò là một điểm vào một dịch vụ cụ thể hoặc một chức năng trong một dịch vụ.

   Thông quan API Endpoint, các ứng dụng máy khách có thể tương tác với các máy chủ, gửi yêu cầu và nhận phản hồi từ nó.

   Thông thường, mỗi API Endpoint có thể ánh xạ với một tính năng duy nhất bên trong máy chủ

2. Giải thích sự khác biệt giữa Cơ sở dữ liệu SQL và NoSQL?

   Các cơ sở dữ liệu SQL (Relational Database - Cơ sở dữ liệu quan hệ) dựa vào lược đồ (hoặc cấu trúc) được xác định trước cho dữ liệu của chúng. Bất cứ khi nào bạn mô tả một bản ghi, hoặc một bảng trong database, bạn thực hiện thông qua định dạng của nó (tên và trường).

   Còn đổi với Cơ sở dữ liệu NoSQL (Non-relational Database), chúng không có lược đồ, vì vậy chúng không định nghĩa trước cấu trúc của dữ liệu. Bạn thường có các tập hợp bản ghi không có có cùng cấu trúc, ngay cả khi chúng biểu diễn cùng một thứ về mặt khái niệm.

3. RESTful API là gì? Và các nguyên tắc cốt lõi của nó?

   Để một API trở thành RESTful (Representational State Transfer), API đó cần phải:

   • API đó cần tuần theo kiến trúc client-server.
   • API đó phải cung cấp một giao diện thống nhất có nghĩa là:
     • Phải có cách để xác minh các tài nguyên với nhau thông qua URI (Unique Resource Identification)
     • Phải có cách để sửa đổi các tài nguyên thông qua cách biểu diễn của chúng.
     • Tin nhắn phải tự mô tả, nghĩa là mỗi tin nhắn phải cung cấp đủ thông tin để hiểu cách xử lý.
     • Các máy khách sử dụng API phải có thể khám phá các hành động khả dụng cho tài nguyên hiện tại bằng cách sử dụng phản hồi được cung cấp từ máy chủ (điều này được gọi là HATEOAS hoặc Hypermedia là Engine of Application State).
   • Nó cần phải không có trạng thái (stateless), nghĩa là mỗi yêu cầu đến máy chủ phải chứa tất cả thông tin để xử lý yêu cầu.
   • Nó phải là một hệ thống nhiều lớp, nghĩa là máy khách và máy chủ không cần phải được kết nối trực tiếp với nhau, có thể có các trung gian, nhưng điều đó không được ảnh hưởng đến giao tiếp giữa máy khách và máy chủ.
   • Tài nguyên phải có thể lưu vào bộ nhớ đệm bởi máy khách hoặc máy chủ.
   • Tùy chọn, máy chủ có thể gửi mã đến máy khách để máy khách thực thi (được gọi là "Mã theo yêu cầu").
4. Bạn có thể mô tả một chu kỳ yêu cầu/phản hồi HTTP thông thường không?

   Giao thức HTTP có cấu trúc rất chặt chẽ và bao gồm một tập hợp các bước được xác định rất rõ ràng:

   • Mở kết nối. Máy khách mở kết nối TCP (Tranmission Control Protocol) tới máy chủ. Cổng sẽ là cổng 80 cho kết nối HTTP và cổng 443 cho kết nối HTTPS (bảo mật).
   • Gửi yêu cầu. Bây giờ máy khách sẽ gửi yêu cầu HTTP tới máy chủ. Yêu cầu chứa thông tin sau:
     • Một phương thức HTTP. Có thể là bất kỳ phương thức nào trong số các phương thức này (ví dụ: GET, POST, PUT, DELETE, v.v.).
     • Một URI (hoặc Mã định danh tài nguyên thống nhất). Điều này chỉ định vị trí của các tài nguyên trên máy chủ.
     • Phiên bản HTTP (thường là HTTP/1.1 hoặc HTTP/2).
     • Một tập hợp các tiêu đề. Chúng bao gồm dữ liệu bổ sung liên quan đến yêu cầu; có danh sách đầy đủ các tiêu đề HTTP có thể được sử dụng tại đây.
     • Phần thân tùy chọn. Tùy thuộc vào loại yêu cầu, bạn cũng sẽ muốn gửi dữ liệu và dữ liệu được mã hóa bên trong phần thân của yêu cầu.
   • Yêu cầu được xử lý bởi máy chủ. Ở giai đoạn này, máy chủ sẽ xử lý yêu cầu và chuẩn bị phản hồi.
   • Gửi phản hồi HTTP trở lại máy khách. Thông qua kênh mở, máy chủ gửi lại phản hồi HTTP. Phản hồi sẽ chứa các thành phần sau:
   • Phiên bản HTTP.
   • Mã trạng thái. Có một danh sách các mã trạng thái tiềm năng mô tả kết quả của yêu cầu.
   • Một tập hợp các tiêu đề có dữ liệu bổ sung.
   • Phần thân tùy chọn, giống như với yêu cầu, phần thân của phản hồi là tùy chọn.
   • Kết nối đã đóng. Đây thường là bước cuối cùng, mặc dù với các phiên bản giao thức mới hơn, có các tùy chọn để giữ kênh mở và tiếp tục gửi yêu cầu và phản hồi qua lại.
5. Bạn xử lý việc tải tệp lên trong ứng dụng web như thế nào?

   Theo quan điểm của một nhà phát triển backend, những cân nhắc sau đây cần được lưu ý khi xử lý tải tệp lên bất kể ngôn ngữ lập trình mà bạn đang sử dụng là gì:

   • Thực hiện xác thực phía máy chủ. Xác thực rằng kích thước tệp của bạn nằm trong phạm vi và tệp có thuộc loại bắt buộc không. Bạn có thể tham khảo hướng dẫn của OWASP.
   • Sử dụng kênh bảo mật. Đảm bảo tệp được tải lên thông qua kết nối HTTPS.
   • Tránh xung đột tên. Đổi tên tệp để đảm bảo tên tệp mới là duy nhất trong hệ thống của bạn. Nếu không, điều này có thể dẫn đến lỗi ứng dụng do không thể lưu các tệp đã tải lên.
   • Lưu siêu dữ liệu về tệp của bạn. Lưu trữ siêu dữ liệu trong cơ sở dữ liệu của bạn hoặc ở nơi khác, nhưng hãy đảm bảo theo dõi siêu dữ liệu đó để bạn có thể cung cấp thêm thông tin cho người dùng. Ngoài ra, nếu bạn đổi tên tệp để bảo mật và tránh xung đột tên, hãy theo dõi tên tệp gốc trong trường hợp người dùng cần tải xuống lại tệp.
6. Bạn sẽ viết những kiểu kiểm tra nào cho một API endpoint mới?

   Với tư cách là các nhà phát triển backend, chúng ta phải nghĩ về các loại kiểm tra hiện có.

   • Unit tests - Kiểm tra đơn vị: Luôn nhớ chỉ kiểm tra logic liên quan thông qua giao diện công khai của mã (tránh kiểm tra các phương thức riêng tư hoặc các hàm không thể truy cập bên trong các mô-đun của bạn). Tập trung vào logic kinh doanh và không cố gắng kiểm tra mã sử dụng các dịch vụ bên ngoài (như cơ sở dữ liệu, đĩa hoặc bất kỳ thứ gì bên ngoài đoạn mã bạn đang kiểm tra).
   • Integration tests - Kiểm tra tích hợp: Kiểm tra toàn bộ endpoint thông qua giao diện công khai của nó (endpoint HTTP thực tế) và xem cách nó tích hợp với các dịch vụ bên ngoài mà nó đang sử dụng (ví dụ như cơ sở dữ liệu, một API khác, v.v.).
   • Load testing / Performance testing - Kiểm tra tải / kiểm tra hiệu suất: Bạn có thể muốn kiểm tra endpoint mới hoạt động như thế nào dưới áp lực nặng. Điều này có thể không cần thiết tùy thuộc vào API bạn đang sử dụng, nhưng theo quy tắc chung, đây là một điều tốt để thực hiện vào cuối giai đoạn phát triển trước khi phát hành endpoint mới vào sản xuất.
7. Mô tả cách quản lý phiên làm việc trong ứng dụng web

   Dưới đây là tổng quan cấp cao về cách quản lý phiên làm việc cho các ứng dụng web:

   • Phiên làm việc được tạo. Điều này xảy ra với lần tương tác đầu tiên của người dùng với hệ thống (trong quá trình đăng nhập). Phần backend của ứng dụng sẽ tạo một ID phiên duy nhất được lưu trữ và trả lại cho người dùng để sử dụng trong các yêu cầu sau này.
   • Lưu trữ thông tin phiên. Dữ liệu phiên cần được lưu trữ ở đâu đó. Dù là trong bộ nhớ hay trong cơ sở dữ liệu, nó cần được lập chỉ mục theo ID phiên từ điểm trước đó. Ở đây, lựa chọn tốt nhất là sử dụng cơ sở dữ liệu (lý tưởng là Redis với hiệu suất I/O cao) để các dịch vụ có thể được mở rộng độc lập với dữ liệu phiên.
   • ID phiên được gửi tới máy khách. Cách phổ biến nhất để làm điều này là thông qua cookie. Phần backend có thể thiết lập một cookie với ID phiên và phần frontend có thể đọc nó một cách an toàn và sử dụng ID theo cách cần thiết.
   • Máy khách gửi ID phiên. Sau khi ID được tạo, ứng dụng máy khách sẽ xác định bản thân với backend bằng cách sử dụng ID này trong mọi yêu cầu.
   • Truy cập dữ liệu phiên ở backend. Backend sẽ truy cập dữ liệu phiên đã lưu trữ bằng cách sử dụng ID phiên nhận được từ máy khách.
   • Phiên được đóng. Sau một thời gian, hoặc có thể do một hành động của người dùng, ID phiên sẽ bị xóa, điều này sẽ khiến dữ liệu phiên bị mất (hoặc bị xóa khỏi CSDL). Điều này hiệu quả là kết thúc các tương tác giữa máy khách và máy chủ như một phần của phiên hiện tại.
8. Bạn tiếp cận API versioning như thế nào trong các dự án của mình?

   Có một số cách để xử lý phiên bản API, nhưng những cách phổ biến nhất là:

   • Giữ phiên bản trong URL: Hoặc là một thuộc tính URL (ví dụ /your-api/users?v=1) hoặc là một phần của URL (ví dụ /v1/your-api/users). Trong cả hai trường hợp, phiên bản đều rõ ràng với nhà phát triển sử dụng API.
   • Sử dụng header tùy chỉnh: Một lựa chọn khác là có một header tùy chỉnh (như api-version) nơi nhà phát triển phải chỉ định phiên bản API họ dự định sử dụng.
9. Bạn bảo vệ máy chủ khỏi các cuộc tấn công SQL injection như thế nào?

   Có nhiều cách để bảo vệ cơ sở dữ liệu quan hệ của bạn khỏi các cuộc tấn công SQL injection, nhưng dưới đây là ba cách rất phổ biến.

   • Câu lệnh được chuẩn bị với các truy vấn có tham số. Đây có lẽ là cách hiệu quả nhất vì nó được thực hiện bởi một thư viện hoặc framework, và tất cả những gì bạn phải làm là viết các truy vấn của mình để lại các điểm giữ chỗ cho nơi dữ liệu được đặt, và sau đó, ở một nơi riêng, cung cấp dữ liệu thực tế.
   • Sử dụng ORM (Ánh xạ Quan hệ-Đối tượng). Các framework này cho phép bạn trừu tượng hóa việc tương tác với cơ sở dữ liệu và tạo các truy vấn SQL cho bạn, có tính đến tất cả các vấn đề bảo mật xung quanh sự tương tác đó.
   • Escaping data - Thoát dữ liệu. Nếu bạn muốn thực hiện thủ công, bạn có thể chăm sóc việc thoát các ký tự đặc biệt có thể phá vỡ cách bạn xây dựng các truy vấn SQL. Việc giữ một danh sách các ký tự bị cấm để thoát trong tình huống này là một ý tưởng hay, để bạn có thể lập trình để đi qua chúng.
10. Giải thích khái niệm stateless trong HTTP và cách nó ảnh hưởng đến các dịch vụ backend

    HTTP theo thiết kế là một giao thức stateless, có nghĩa là mỗi yêu cầu là duy nhất và không liên quan đến bất kỳ yêu cầu nào trước đó, ngay cả từ cùng một máy khách.

    Điều này ảnh hưởng đến các dịch vụ web backend bằng cách buộc chúng phải triển khai các giải pháp quản lý trạng thái riêng nếu như tính năng như vậy được yêu cầu.

11. Containerization là gì, và làm thế nào nó mang lại lợi ích cho phát triển backend?

    Đó là một phương pháp ảo hóa nhẹ để đóng gói các ứng dụng và các phụ thuộc của chúng, đảm bảo môi trường nhất quán trên các hệ thống khác nhau.

    Nó thực sự là một lợi ích cho phát triển backend vì nó cung cấp sự cô lập và tính di động bằng cách đơn giản hóa các quy trình triển khai và giảm các xung đột giữa các phiên bản và cấu hình phần mềm.

12. Bạn sẽ thực hiện những biện pháp nào để bảo mật một API mới phát triển?

    Có nhiều cách để bảo mật một API, dưới đây là một số cách phổ biến nhất:

    • Thêm một phương thức xác thực, như OAuth, JWT, Bearer tokens, Xác thực dựa trên phiên, và các phương thức khác.
    • Sử dụng HTTPS để mã hóa việc truyền dữ liệu giữa máy khách và máy chủ.
    • Cấu hình các chính sách CORS mạnh để tránh các yêu cầu không mong muốn.
    • Thiết lập một logic ủy quyền mạnh, để đảm bảo các máy khách chỉ truy cập các tài nguyên mà họ được phép truy cập.
13. Bạn sẽ mở rộng quy mô một ứng dụng backend như thế nào trong thời điểm lưu lượng truy cập tăng đột biến?

    Cách phổ biến nhất để mở rộng quy mô một ứng dụng backend trong thời điểm lưu lượng truy cập tăng đột biến là có nhiều phiên bản của ứng dụng đằng sau một bộ cân bằng tải, và khi lưu lượng truy cập tăng đột biến, chỉ cần thêm nhiều phiên bản của ứng dụng.

    Đây được gọi là mở rộng quy mô theo chiều ngang và hoạt động tốt nhất khi ứng dụng backend là stateless.

    

14. Bạn sử dụng những công cụ và kỹ thuật nào để gỡ lỗi một ứng dụng backend?

    Nếu ứng dụng backend đang được gỡ lỗi trên máy phát triển cục bộ, một giải pháp đơn giản sẽ là sử dụng chính IDE. Hầu hết các IDE hiện đại, như IntelliJ, Eclipse và những IDE khác đều có khả năng gỡ lỗi tích hợp.

    Tuy nhiên, nếu ứng dụng backend nằm trên máy chủ, bạn sẽ phải sử dụng các kỹ thuật khác, chẳng hạn như ghi nhật ký, mà bạn có thể thực hiện với các thư viện ghi nhật ký. Hoặc, bạn có thể sử dụng các công cụ phức tạp hơn như JProfiler hoặc NewRelic.

15. Làm thế nào để đảm bảo mã backend của bạn dễ duy trì và dễ hiểu?

    Bí quyết ở đây là tuân theo các phương pháp hay và các tiêu chuẩn mã như:

    • Tính mô-đun.
    • Tuân theo các quy ước đặt tên.
    • Thêm các nhận xét mã.
    • Thực hiện refactor thường xuyên để kiểm soát nợ kỹ thuật.
    • Giữ cho các thông báo xử lý lỗi nhất quán trên toàn bộ nền tảng.
    • Thực hiện các bài kiểm tra đơn vị trên tất cả các mã đã viết.

Intermediate Level

1. Mô tả cách bạn sẽ triển khai tìm kiếm toàn văn bản trong cơ sở dữ liệu

   Bạn có thể sử dụng chức năng tìm kiếm toàn văn bản gốc của cơ sở dữ liệu, chẳng hạn như MySQL, Postgre hoặc thậm chí là ElasticSearch.

   Tuy nhiên, nếu bạn muốn tự mình triển khai nó, các bước sẽ là:

   • Xử lý trước dữ liệu văn bản cần tìm kiếm và chuẩn hóa nó bằng cách áp dụng phân token, stemming và loại bỏ các từ dừng (stop words).
   • Sau đó, triển khai một chỉ mục đảo ngược, bằng cách nào đó liên quan đến từng từ duy nhất với các bản ghi chứa từ đó.
   • Tạo giao diện tìm kiếm và chuẩn hóa đầu vào từ người dùng theo cùng cách dữ liệu văn bản được chuẩn hóa.
   • Sau đó, tìm kiếm từng từ trong cơ sở dữ liệu.
   • Sắp xếp kết quả bằng cách triển khai logic tính điểm dựa trên các khía cạnh khác nhau, chẳng hạn như tần suất từ.
2. Bạn sẽ tiếp cận xử lý hàng loạt trong một ứng dụng back-end nhiều dữ liệu như thế nào?

   Lựa chọn tốt nhất ở đây là sử dụng một khung xử lý hàng loạt như Hadoop hoặc Spark. Chúng đã được chuẩn bị sẵn sàng để xử lý khối lượng dữ liệu khổng lồ song song.

3. Bạn có thể giải thích việc sử dụng và lợi ích của hàng đợi message trong hệ thống phân tán không?

   

   Hàng đợi message trong hệ thống phân tán có thể hoạt động như thành phần cốt lõi của kiến trúc phản ứng. Mỗi dịch vụ có thể kích hoạt và lắng nghe các sự kiện đến từ hàng đợi. Bằng cách đó, khi các sự kiện đến, các dịch vụ đó có thể phản ứng với chúng mà không cần phải tích cực thăm dò các dịch vụ khác để lấy phản hồi.

4. Bạn sẽ sử dụng chiến lược nào để quản lý kết nối cơ sở dữ liệu trong kịch bản tải cao?

   Trong kịch bản tải cao, nhà phát triển có thể thực hiện một số điều để cải thiện hiệu suất của kết nối cơ sở dữ liệu:

   • Sử dụng các nhóm kết nối để tái sử dụng các kết nối giúp giảm thời gian cần thiết để thiết lập một kết nối mới.
   • Cân bằng tải lưu lượng truy cập cơ sở dữ liệu (các truy vấn) giữa một nhóm các cơ sở dữ liệu sẽ giúp phân phối tải.
   • Ngay cả việc tối ưu hóa các truy vấn của bạn cũng có thể giảm thời gian bạn sử dụng mỗi kết nối, giúp bạn tối ưu hóa việc sử dụng tài nguyên và giảm thiểu thời gian bạn dành cho mỗi kết nối đang hoạt động.
5. Bạn sẽ thiết lập pipeline tích hợp/cung cấp liên tục (CI/CD) cho các dịch vụ back-end như thế nào?

   Có nhiều cân nhắc trong khi thiết lập pipeline tích hợp và cung cấp liên tục:

   • Sử dụng kiểm soát nguồn làm yếu tố kích hoạt cho toàn bộ quá trình (ví dụ: git). Pipeline xây dựng cho các dịch vụ back-end của bạn nên được thực thi khi bạn đẩy mã của mình vào một nhánh cụ thể.
   • Chọn nền tảng CI/CD phù hợp cho nhu cầu của bạn, có rất nhiều nền tảng ngoài kia chẳng hạn như GitHub Actions, GitLab CI/CD, CircleCI, v.v.
   • Hãy chắc chắn rằng bạn có các bài kiểm tra đơn vị tự động có thể được thực thi bên trong các pipeline này.
   • Triển khai tự động chỉ nên xảy ra nếu tất cả các bài kiểm tra được thực thi thành công, nếu không, pipeline sẽ thất bại, ngăn chặn mã bị hỏng đến bất kỳ môi trường nào.
   • Sử dụng kho lưu trữ tác phẩm chẳng hạn như JFrog Artifactory hoặc Nexus Repository để lưu trữ các dịch vụ được xây dựng thành công.
   • Cuối cùng, hãy xem xét thiết lập một chiến lược khôi phục trong trường hợp có điều gì đó không ổn và phiên bản cuối cùng được triển khai của dịch vụ bị hỏng theo một cách nào đó.
6. Bạn có thể mô tả một chiến lược caching phân tán cho một ứng dụng có tính sẵn sàng cao không?

   Trong trường hợp này, bạn cần xem xét các điểm sau:

   • Triển khai một cụm máy chủ để tất cả các máy chủ này hoạt động như cache phân tán. Thực hiện quy trình phân chia dữ liệu (data sharding) để phân phối dữ liệu đồng đều giữa các máy chủ cache và đảm bảo sử dụng thuật toán băm nhất quán (consistent hashing) để giảm thiểu việc tái cấu trúc cache khi một máy chủ tham gia hoặc rời khỏi cụm.
   • Thêm sao chép cache (cache replication) để có tính dự phòng dữ liệu trong trường hợp xảy ra lỗi, điều này đảm bảo cache phân tán của bạn cũng có khả năng chịu lỗi.
   • Xóa cache (cache invalidation) là điều bắt buộc trong bất kỳ giải pháp caching nào, vì dữ liệu của bạn sẽ trở nên lỗi thời nếu không được cập nhật thường xuyên.
7. Bạn có thể sử dụng những phương pháp nào để quản lý các tác vụ nền trong ứng dụng của mình?

   Điều này phụ thuộc rất nhiều vào ngăn xếp công nghệ của bạn và các tác vụ nền đó đang làm gì. Vì vậy, có nhiều lựa chọn:

   • Sử dụng các hàng đợi tác vụ như RabbitMQ hoặc Amazon SQS. Điều này cho phép bạn có các worker chạy nền như các quy trình phụ trong khi ứng dụng của bạn vẫn tiếp tục hoạt động.
   • Có các framework cho tác vụ nền như Celery cho Python hoặc Sidekiq cho Ruby.
   • Bạn cũng có thể chỉ sử dụng cron jobs nếu muốn.
   • Nếu ngôn ngữ lập trình của bạn cho phép, bạn cũng có thể sử dụng luồng (threads) hoặc các worker để chạy các tác vụ này trong nền nhưng trong cùng một ứng dụng.
8. Bạn xử lý mã hóa và giải mã dữ liệu như thế nào trong một ứng dụng tập trung vào quyền riêng tư?

   Đối với loại ứng dụng này, bạn cần phân biệt giữa “dữ liệu ở trạng thái nghỉ” (data at rest) và “dữ liệu trong quá trình truyền” (data in transit). Dữ liệu ở trạng thái nghỉ mô tả dữ liệu của bạn khi được lưu trữ trong cơ sở dữ liệu (hoặc bất kỳ nơi lưu trữ nào). Dữ liệu trong quá trình truyền mô tả dữ liệu của bạn khi nó đang di chuyển giữa các dịch vụ backend hoặc giữa máy chủ và client.

   Đối với “dữ liệu trong quá trình truyền”, bạn nên đảm bảo rằng kết nối diễn ra trong một kênh an toàn và được mã hóa như HTTPS.

   Và đối với “dữ liệu ở trạng thái nghỉ”, hãy sử dụng các thuật toán mã hóa mạnh như AES, RSA hoặc ECC và đảm bảo giữ các khóa liên quan ở nơi an toàn, chẳng hạn như trong các công cụ quản lý bí mật chuyên dụng hoặc các dịch vụ quản lý khóa (KMS).

9. Webhook là gì và bạn đã triển khai chúng trong các dự án trước đây như thế nào?

   Webhooks là các callback HTTP do người dùng định nghĩa, chúng được kích hoạt bởi một sự kiện cụ thể trong hệ thống. Chúng chủ yếu được sử dụng để thông báo về kết quả của các tác vụ bất đồng bộ, nhiều bước nhằm tránh việc giữ kết nối HTTP mở.

   Về việc triển khai webhook, hãy xem xét các điểm sau:

   • Định nghĩa sự kiện. Đảm bảo định nghĩa chính xác những sự kiện nào sẽ kích hoạt thông báo tới webhook và loại payload liên quan đến những sự kiện đó.
   • Tạo endpoint. Dựa trên bước trước, định nghĩa một endpoint HTTP có thể xử lý yêu cầu mong đợi (đặc biệt là phần payload). Nói cách khác, nếu bạn nhận dữ liệu trong yêu cầu webhook, hãy đảm bảo tạo endpoint dưới dạng POST, nếu không, bạn có thể sử dụng GET.
   • Bảo mật. Nhớ triển khai một số biện pháp bảo mật xung quanh endpoint webhook để tránh bị khai thác.
10. Những yếu tố nào cần được cân nhắc để tuân thủ GDPR (General Data Protection Regulation) trong một hệ thống backend?

    Dưới đây là các yếu tố quan trọng cần được xem xét:

    • Chỉ thu thập những gì bạn cần và những gì bạn đã thông báo cho người dùng sẽ thu thập. Hãy nhớ rằng để tuân thủ GDPR, bạn phải xin sự đồng ý của người dùng để thu thập dữ liệu của họ và bạn phải nêu rõ các điểm dữ liệu thực tế mà bạn đang thu thập. Vì vậy, hãy tập trung vào những điểm này và không gì khác.
    • Bảo mật dữ liệu của bạn. Là một phần của quy định, bạn phải đảm bảo rằng dữ liệu của mình được bảo mật cả khi truyền tải và khi lưu trữ. Cần thực hiện các kiểm tra bảo mật thường xuyên để đảm bảo mức độ bảo mật luôn cao.
    • Người dùng có quyền đối với dữ liệu mà bạn đã thu thập, vì vậy hãy đảm bảo cung cấp cho họ các endpoint hoặc dịch vụ để đọc, chỉnh sửa hoặc thậm chí xóa dữ liệu nếu họ muốn.
11. Hãy giải thích cách bạn xử lý các quy trình chạy lâu trong các yêu cầu web

    

    Đối với các yêu cầu web kích hoạt các quy trình chạy lâu, giải pháp tốt nhất là triển khai kiến trúc phản ứng (reactive architecture). Điều này có nghĩa là khi một dịch vụ nhận được yêu cầu, nó sẽ chuyển đổi yêu cầu thành một thông điệp trong hàng đợi thông điệp (message queue), và quy trình chạy lâu sẽ xử lý thông điệp này khi sẵn sàng.

    Trong thời gian đó, client gửi yêu cầu này sẽ nhận được phản hồi ngay lập tức xác nhận rằng yêu cầu đang được xử lý. Chính client cũng có thể được kết nối với hàng đợi thông điệp (hoặc qua proxy) và chờ sự kiện “sẵn sàng” với payload bên trong.

12. Thảo luận về việc triển khai giới hạn tốc độ để bảo vệ API khỏi lạm dụng

    Để triển khai giới hạn tốc độ (rate limiting), bạn cần lưu ý các điểm sau:

    • Định nghĩa giới hạn của bạn. Xác định chính xác số lượng yêu cầu mà một client có thể thực hiện. Điều này có thể được đo bằng số yêu cầu mỗi phút, mỗi ngày hoặc mỗi giây.
    • Chọn chiến lược giới hạn. Chọn một thuật toán giới hạn tốc độ, như bộ đếm cửa sổ cố định (fixed window counter), cửa sổ trượt (sliding log window), token bucket, hoặc leaky bucket. Bạn có thể đọc thêm về các thuật toán này tại đây.
    • Lưu trữ bộ đếm của bạn. Sử dụng một kho dữ liệu nhanh (như Redis) để theo dõi số lượng yêu cầu hoặc dấu thời gian cho mỗi client.
    • Khi đạt đến giới hạn, hãy cố gắng phản hồi bằng mã trạng thái tiêu chuẩn, chẳng hạn như 429, cho biết rằng đã có “Quá nhiều yêu cầu” (Too Many Requests).

    Nếu bạn muốn tiến xa hơn, hãy cân nhắc sử dụng một API Gateway có sẵn chức năng này hoặc bổ sung hỗ trợ cho các đợt tăng lưu lượng đột ngột để tránh phạt các client vượt nhẹ giới hạn trong một vài lần.

13. Bạn làm thế nào để đo lường và giám sát hiệu suất của ứng dụng backend?

    Một cách tuyệt vời để giám sát hiệu suất của các ứng dụng backend là sử dụng hệ thống Quản lý Hiệu suất Ứng dụng (Application Performance Management - APM) như New Relic, AppDynamics hoặc Dynatrace.

    Các hệ thống này sẽ theo dõi hiệu suất ứng dụng của bạn và cung cấp thông tin chi tiết về các nút thắt cổ chai mà bạn có thể gặp phải với nỗ lực tối thiểu từ phía bạn.

14. Microservices là gì và làm thế nào để tách một monolith thành microservices?

    Microservices là một phong cách kiến trúc phần mềm cho phép bạn cấu trúc các ứng dụng backend thành một tập hợp các dịch vụ độc lập, mỗi dịch vụ tập trung vào một nhu cầu kinh doanh cụ thể.

    Nếu bạn muốn tách một monolith thành một tập hợp các microservices, bạn cần lưu ý những điểm sau:

    • Bắt đầu bằng cách xác định các ranh giới logic của monolith. Bên trong, monolith sẽ xử lý nhiều trách nhiệm và loại tài nguyên khác nhau. Tìm các ranh giới giữa chúng để hiểu nơi một dịch vụ kết thúc và một dịch vụ khác bắt đầu.
    • Định nghĩa các dịch vụ của bạn dựa trên ranh giới đã xác định và bắt đầu tách riêng nhu cầu dữ liệu. Điều này có thể được thực hiện thông qua nhiều bảng dữ liệu hoặc thậm chí các cơ sở dữ liệu riêng biệt khi cần thiết.
    • Bắt đầu cải tiến từng bước monolith và trích xuất logic cần thiết cho từng microservice vào dự án riêng của nó.

    Khi hoàn thành, monolith gốc của bạn sẽ không còn cần thiết nữa, và tất cả các microservice sẽ có pipeline triển khai độc lập và kho mã nguồn riêng.

15. Bạn đã quản lý các phụ thuộc API trong hệ thống backend như thế nào?

    Một cách tuyệt vời để xử lý các phụ thuộc API trong hệ thống backend là tận dụng phiên bản hóa API (API versioning). Với thực hành đơn giản này, bạn có thể đảm bảo rằng hệ thống của mình thực sự sử dụng đúng API, ngay cả khi có nhiều phiên bản API khác nhau.

    Điều này cũng cho phép bạn có nhiều hệ thống backend sử dụng các phiên bản khác nhau của cùng một API mà không có nguy cơ không đồng bộ hoặc các bản cập nhật làm hỏng hệ thống của bạn.

16. Hãy mô tả khái niệm nhất quán cuối cùng (eventual consistency) và tác động của nó đối với hệ thống backend

    

    Nhất quán cuối cùng (eventual consistency) là một mô hình nhất quán được sử dụng trong điện toán phân tán. Mô hình này đảm bảo rằng bất kỳ thông tin nào được ghi vào một hệ thống phân tán sẽ trở nên nhất quán (nghĩa là tất cả các máy chủ sẽ có cùng một phiên bản dữ liệu này) cuối cùng, thay vì nhất quán ngay lập tức như các mô hình khác.

    Đối với hệ thống backend, điều này có nghĩa là cần có sự đồng bộ dữ liệu giữa tất cả các phần của hệ thống phân tán. Đồng thời, có thể cần giải quyết xung đột dữ liệu nếu các phần khác nhau của hệ thống xử lý các phiên bản khác nhau của cùng một bản ghi dữ liệu.

17. Reverse proxy là gì, và nó hữu ích như thế nào trong phát triển backend?

    Một reverse proxy là một máy chủ đứng trước nhiều máy chủ khác và chuyển hướng lưu lượng truy cập đến các máy chủ web đó dựa trên các quy tắc logic khác nhau. Ví dụ, bạn có thể có hai máy chủ web, một dành cho khách hàng của doanh nghiệp bạn và một dành cho nhân viên của bạn.

    Bạn có thể cấu hình reverse proxy để chuyển hướng lưu lượng truy cập đến một trong hai tùy thuộc vào giá trị của một header được gửi trong yêu cầu hoặc URL thực tế được yêu cầu.

    Nó rất hữu ích trong phát triển backend vì nó cho phép bạn làm nhiều việc khác nhau, ví dụ:

    • Phân tải lưu lượng giữa nhiều phiên bản của cùng một dịch vụ backend.
    • Cung cấp một lớp bảo mật bổ sung bằng cách ẩn vị trí của các dịch vụ backend và xử lý các cuộc tấn công, chẳng hạn như DDoS.
    • Có thể lưu trữ cache nội dung, giảm tải cho các máy chủ web của bạn.
    • Cho phép bạn thay đổi các dịch vụ backend mà không ảnh hưởng đến các URL hướng ra ngoài.
18. Bạn sẽ xử lý trạng thái phiên (session state) trong môi trường ứng dụng cân bằng tải như thế nào?

    Trong một kịch bản ứng dụng cân bằng tải, vấn đề chính với trạng thái phiên là nếu hệ thống backend xử lý dữ liệu phiên trong bộ nhớ, thì các yêu cầu tiếp theo từ cùng một client cần được chuyển đến cùng một máy chủ. Nếu không, dữ liệu phiên sẽ bị phân mảnh và vô dụng.

    Có hai cách chính để giải quyết vấn đề này:

    • Sticky sessions: Cho phép bạn cấu hình load balancer để chuyển hướng các yêu cầu từ cùng một client đến cùng một máy chủ mỗi lần. Điểm hạn chế của phương pháp này là lưu lượng không phải lúc nào cũng được phân phối đều giữa tất cả các bản sao của dịch vụ backend.
    • Lưu trữ phiên tập trung: Giải pháp này liên quan đến việc chuyển dữ liệu phiên ra khỏi các dịch vụ backend vào một kho dữ liệu tập trung mà tất cả các bản sao dịch vụ của bạn có thể truy cập. Điều này làm giảm tải cho load balancer, nhưng yêu cầu logic bổ sung và thêm các thành phần hoạt động phức tạp hơn.

    Việc lựa chọn chiến lược nào phù hợp nhất phụ thuộc vào yêu cầu kỹ thuật cụ thể của bạn.

Advanced Level

1. Sao chép cơ sở dữ liệu là gì, và làm thế nào để sử dụng nó cho khả năng chịu lỗi?

   Sao chép cơ sở dữ liệu ngụ ý việc sao chép dữ liệu trên nhiều phiên bản của cùng một cơ sở dữ liệu. Trong trường hợp này, thường có một cơ sở dữ liệu đóng vai trò là máy chủ chính cho tất cả các máy khách kết nối, và các máy còn lại hoạt động như "máy con" chỉ đơn giản là nhận các bản cập nhật về dữ liệu được thay đổi/thêm vào.

   Hai ảnh hưởng chính của điều này đối với khả năng chịu lỗi là:

   • Một cụm cơ sở dữ liệu có thể chịu đựng các vấn đề trên máy chủ chính bằng cách thăng cấp một trong các máy con mà không mất bất kỳ dữ liệu nào trong quá trình này.
   • Các máy con có thể được sử dụng làm máy chủ chỉ đọc, tăng số lượng yêu cầu đọc có thể được thực hiện trên dữ liệu mà không ảnh hưởng đến hiệu suất của cơ sở dữ liệu.
2. Mô tả chiến lược triển khai xanh-xanh (blue-green) trong các dịch vụ backend

   Chiến lược xanh-xanh liên quan đến việc có hai môi trường sản xuất giống hệt nhau, một trong số đó phục vụ lưu lượng truy cập thực tế trong khi môi trường kia đang được chuẩn bị để cập nhật phiên bản tiếp theo hoặc chỉ đơn giản là chờ đợi để được sử dụng như một bản sao dự phòng.

3. Bạn có thể giải thích các mô hình nhất quán trong các cơ sở dữ liệu phân tán (ví dụ: định lý CAP) không?

   

   Định lý CAP nói rằng các cơ sở dữ liệu phân tán không thể đồng thời cung cấp nhiều hơn hai trong số các đảm bảo sau:

   • Tính nhất quán dữ liệu: Có nghĩa là mỗi lần đọc luôn trả về kết quả mới nhất của hoạt động ghi. Điều này rất quan trọng trong mô hình này vì chúng ta đang xử lý nhiều máy chủ và dữ liệu cần được sao chép gần như ngay lập tức để đảm bảo tính nhất quán.
   • Tính khả dụng: Có nghĩa là mọi yêu cầu sẽ luôn nhận được một phản hồi hợp lệ.
   • Khả năng chịu phân vùng: Hệ thống phân tán tiếp tục hoạt động và làm việc mà không mất dữ liệu ngay cả trong các sự cố mạng một phần.

   Ví dụ, nếu hệ thống là nhất quán và có tính khả dụng cao, nó sẽ không thể chịu đựng các sự cố mạng một phần. Mặt khác, nếu hệ thống có tính khả dụng cao và khả năng chịu phân vùng, nó sẽ không thể đảm bảo tính nhất quán dữ liệu ngay lập tức.

4. Làm thế nào để quản lý các di chuyển lược đồ trong môi trường phân phối liên tục?

   Hai khía cạnh chính cần xem xét khi quản lý các di chuyển lược đồ, đặc biệt là trong môi trường CD là:

   • Theo dõi các di chuyển lược đồ của bạn bên trong kiểm soát phiên bản. Giữ các tệp này phiên bản cùng với mã của bạn, vì có mối quan hệ trực tiếp giữa các phiên bản đó.
   • Sử dụng các công cụ di chuyển tự động như Flyway hoặc Liquibase để đơn giản hóa quá trình và giữ cho nó ở mức tiêu chuẩn.
5. Có những chiến lược nào để xử lý tính đơn trị trong thiết kế API REST?

   Đối với các API REST, bạn có thể tận dụng các HTTP verb và xác định các hoạt động đơn trị bằng cách sử dụng các verb vốn có tính đơn trị, như GET, PUT và DELETE.

   Hoặc bạn luôn có thể thực hiện thủ công logic dựa trên khóa để tránh lặp lại cùng một hoạt động nhiều lần nếu khóa do máy khách cung cấp luôn giống nhau.

6. Mô tả việc triển khai giải pháp đăng nhập một lần (SSO)

   Ở mức độ rất cao, các bước để triển khai một giải pháp SSO là:

   • Chọn một nhà cung cấp danh tính, chẳng hạn như Okta hoặc Keycloack.
   • Sau đó, mỗi ứng dụng sẽ tích hợp với Nhà cung cấp Danh tính từ bước trước bằng cách sử dụng một giao thức SSO tiêu chuẩn, như SAML, OpenID hoặc bất kỳ giao thức nào khác.
   • Đối với lần truy cập đầu tiên của người dùng, ứng dụng sẽ kết nối với IdP và xác thực người dùng, nhận lại một mã truy cập.
   • Sau đó, trong các yêu cầu tiếp theo, ứng dụng sẽ xác thực mã được cung cấp thông qua IdP.
7. Giải thích làm thế nào bạn sẽ phát triển một hệ thống backend để xử lý các luồng dữ liệu thiết bị IoT

   

   Một kiến trúc chụp và xử lý dữ liệu thời gian thực sẽ yêu cầu các thành phần sau:

   • Sử dụng một dịch vụ thu thập dữ liệu có thể mở rộng như Kafka hoặc AWS Kinesis tương thích với một trong nhiều giao thức IoT tiêu chuẩn (như MQTT hoặc CoAP).
   • Xử lý dữ liệu thông qua các công cụ xử lý thời gian thực như Apache Flink hoặc Spark Streaming.
   • Lưu trữ dữ liệu bên trong một hồ dữ liệu có thể mở rộng, lý tưởng là một hệ thống tương thích với chuỗi thời gian như InfluxDB.
8. Làm thế nào bạn sẽ thiết kế một backend để hỗ trợ đồng bộ hóa dữ liệu thời gian thực giữa các thiết bị?

   Nếu bạn muốn hỗ trợ đồng bộ hóa dữ liệu thời gian thực, bạn sẽ phải tìm cách tạo các kênh giao tiếp ổn định và hiệu quả giữa các thiết bị và tìm cách giải quyết các xung đột đồng bộ hóa dữ liệu khi một số thiết bị đang cố gắng thay đổi cùng một bản ghi.

   Vì vậy, đối với các kênh giao tiếp, bạn có thể sử dụng một trong những phương án sau:

   • Các kênh hai chiều dựa trên socket cho phép trao đổi dữ liệu thời gian thực.
   • Sử dụng mô hình pub/sub để phân phối dữ liệu một cách hiệu quả giữa nhiều thiết bị. Bạn có thể sử dụng thứ gì đó như Redis hoặc Kafka cho việc này.

   Để giải quyết các xung đột dữ liệu, bạn có thể sử dụng các thuật toán như Phép biến đổi Hoạt động (OT) hoặc Kiểu Dữ liệu Sao chép Không có Xung đột (CRDTs).

9. Thảo luận về các ưu điểm và nhược điểm của kiến trúc microservice trong các hệ thống backend

   Ưu điểm:

   • Khả năng mở rộng: các microservice có thể mở rộng một cách độc lập với nhau.
   • Tính linh hoạt về công nghệ: bạn có thể sử dụng các ngăn xếp công nghệ khác nhau tùy thuộc vào nhu cầu cụ thể của từng microservice.
   • Triển khai nhanh hơn: các microservice có thể được triển khai một cách riêng lẻ, cải thiện tốc độ mà bạn đưa các thay đổi vào sản xuất.

   Nhược điểm:

   • Kiến trúc quá phức tạp. Trong một số tình huống, kiến trúc dựa trên microservice có thể trở nên quá phức tạp để quản lý và điều phối.
   • Gỡ lỗi: Việc gỡ lỗi các vấn đề trong kiến trúc dựa trên microservices có thể khó khăn vì dữ liệu chảy qua nhiều dịch vụ trong một yêu cầu duy nhất.
   • Chi phí giao tiếp: So với cách tiếp cận monolithic, giao tiếp giữa các microservices có thể quá phức tạp.

   Bạn sẽ tiếp cận việc kiểm tra tải cho một API backend như thế nào?

   • Đầu tiên bạn phải hiểu các mục tiêu và thiết lập môi trường thử nghiệm. Lý tưởng nhất, môi trường của bạn sẽ giống với môi trường sản xuất.
   • Thiết kế và triển khai các bài kiểm tra của bạn với các công cụ bạn đã chọn (như JMeter, LoadRunner hoặc bất kỳ công cụ nào khác).
   • Bắt đầu tăng dần tải trong các bài kiểm tra của bạn trong khi theo dõi hiệu suất và độ ổn định của hệ thống.
   • Tối ưu hóa API backend của bạn và quay lại bước đầu tiên để thiết kế lại các bài kiểm tra, sau đó thử lại cho đến khi bạn hài lòng với kết quả.
10. Bạn sẽ tiếp cận việc kiểm tra tải cho một API backend như thế nào?
    • Đầu tiên, bạn cần hiểu rõ mục tiêu và thiết lập môi trường kiểm tra. Lý tưởng nhất là môi trường của bạn nên giống với môi trường sản xuất.
    • Thiết kế và triển khai các bài kiểm tra của bạn với các công cụ bạn đã chọn (chẳng hạn như JMeter, LoadRunner hoặc bất kỳ công cụ nào khác).
    • Bắt đầu tăng dần tải trên các bài kiểm tra của bạn trong khi giám sát hiệu suất và sự ổn định của hệ thống.
    • Tối ưu hóa API backend của bạn và quay lại bước đầu tiên để thiết kế lại các bài kiểm tra và thử lại cho đến khi bạn hài lòng với kết quả.
11. Mô tả cách bạn sẽ triển khai chiến lược xóa bộ nhớ đệm phía máy chủ

    Để xác định chiến lược này, bạn cần định nghĩa các yếu tố sau:

    • Giới hạn kích thước sẽ kích hoạt việc xóa bộ nhớ đệm khi vượt quá.
    • Một chiến lược giám sát để xác định xem chiến lược xóa có hoạt động hiệu quả hay cần điều chỉnh.
    • Một cơ chế làm mất hiệu lực bộ nhớ đệm.
    • Một chính sách xóa, có thể là một trong các chính sách sau:
      • LRU (Least Recently Used): Xóa các mục được truy cập gần đây nhất.
      • LFU (Least Frequently Used): Loại bỏ các mục ít được truy cập nhất.
      • FIFO (First-In, First-Out): Xóa các mục theo thứ tự chúng được thêm vào.
      • Random: Chọn ngẫu nhiên các mục để xóa.
      • TTL (Time-To-Live): Loại bỏ các mục sau một khoảng thời gian nhất định.
12. Correlation ID là gì và chúng được sử dụng như thế nào để theo dõi yêu cầu giữa các dịch vụ?

    Correlation ID là các định danh duy nhất được thêm vào các yêu cầu trong kiến trúc phân tán để giúp theo dõi yêu cầu xuyên suốt kiến trúc. Lưu ý rằng thông thường, khi một yêu cầu truy cập hệ thống backend phân tán, dữ liệu từ yêu cầu sẽ đi qua nhiều dịch vụ web trước khi tạo ra phản hồi.

    Điều này giúp dễ dàng hiểu được hành trình mỗi yêu cầu đi qua, nhằm gỡ lỗi các vấn đề tiềm năng hoặc cải thiện hiệu suất.

13. Giải thích sự khác biệt giữa khóa lạc quan và khóa bi quan và khi nào nên sử dụng mỗi loại

    Khóa lạc quan là một chiến lược mà:

    • Giả định rằng xung đột hiếm khi xảy ra.
    • Cho phép truy cập dữ liệu đồng thời.
    • Kiểm tra xung đột trước khi xác nhận giao dịch.
    • Phù hợp nhất trong các kịch bản đọc cao, ghi thấp.

    Khóa bi quan, ngược lại, là một chiến lược mà:

    • Giả định rằng xung đột rất phổ biến.
    • Khóa dữ liệu và ngăn chặn truy cập đồng thời.
    • Giữ các khóa này trong suốt thời gian giao dịch.
    • Phù hợp nhất trong các kịch bản ghi cao hoặc khi tính toàn vẹn dữ liệu là quan trọng.
14. Những phương pháp nào bạn sẽ sử dụng để ngăn ngừa deadlock trong giao dịch cơ sở dữ liệu?

    Có nhiều cách để ngăn ngừa deadlock trong giao dịch cơ sở dữ liệu; một số phương pháp phổ biến nhất là:

    • Sử dụng thứ tự khóa để lấy khóa theo một thứ tự toàn cầu nhất quán, tránh các điều kiện chờ vòng tròn.
    • Sử dụng timeouts cho giao dịch cơ sở dữ liệu để tự động kết thúc các thao tác lâu dài có thể dẫn đến deadlock.
    • Sử dụng điều khiển đồng thời lạc quan khi có thể, để tránh giữ khóa quá lâu.
15. Làm thế nào bạn sẽ bảo mật giao tiếp giữa các dịch vụ trong kiến trúc microservices?

    Bắt đầu từ cơ sở hiểu rằng giao tiếp giữa các dịch vụ của bạn chỉ nên diễn ra trong các mạng riêng tư (lý tưởng nhất là không có lưu lượng công khai nào nên đến các dịch vụ này), dưới đây là một số khuyến nghị:

    • Sử dụng các kênh mã hóa, như TLS để ngăn chặn các cuộc tấn công phổ biến như man-in-the-middle.
    • Sử dụng API gateway để quản lý và xác thực lưu lượng truy cập đến mạng riêng này.
    • Thiết lập xác thực và phân quyền cho các tin nhắn giữa các dịch vụ, đảm bảo rằng chỉ các microservice hợp lệ mới có thể giao tiếp với nhau, và khi chúng làm vậy, chúng chỉ có quyền truy cập vào những gì phù hợp với chức năng của chúng.
16. Thảo luận về các kỹ thuật ngăn chặn và phát hiện sự bất thường trong dữ liệu trong các hệ thống quy mô lớn

    Một số kỹ thuật phổ biến bao gồm:

    • Thêm và triển khai các quy tắc xác thực để ngăn chặn việc nhập dữ liệu không hợp lệ. Thông qua việc định nghĩa các sơ đồ và các ràng buộc của sơ đồ để thực thi các tiêu chuẩn tối thiểu nhất định, bạn có thể ngăn ngừa sự bất thường trong dữ liệu xảy ra.
    • Triển khai phiên bản hóa dữ liệu để dễ dàng quay lại nếu phát hiện có sự bất thường.
    • Triển khai một quy trình kiểm soát chất lượng dữ liệu mạnh mẽ để đảm bảo rằng bất kỳ thông tin nào vào hệ thống của bạn đều được xác thực đúng cách và đánh dấu nếu cần thiết.
17. Mô tả quy trình xây dựng một giải pháp lưu trữ dữ liệu toàn cầu, có tính sẵn sàng cao cho một ứng dụng đa quốc gia

    Xây dựng một giải pháp lưu trữ dữ liệu có tính sẵn sàng cao bao gồm nhiều lĩnh vực, bao gồm:

    • Môi trường đa khu vực. Nếu bạn chọn các giải pháp dựa trên đám mây (như Azure, AWS, GCP hoặc các dịch vụ khác), thì yêu cầu này sẽ được đáp ứng ngay lập tức (ngoại trừ một số khu vực cụ thể trên thế giới). Điều này giúp đảm bảo tính sẵn sàng ngay cả khi có sự cố mạng một phần.
    • Nhân bản dữ liệu. Đảm bảo rằng dữ liệu của bạn được nhân bản giữa các máy chủ của tất cả các khu vực. Điều này giúp đảm bảo rằng nếu có sự cố khiến một số máy chủ (hoặc thậm chí toàn bộ khu vực) bị ngừng hoạt động, sẽ không có mất mát dữ liệu.
    • Cân bằng tải. Đảm bảo rằng lưu lượng truy cập được cân bằng tải hợp lý giữa tất cả các khu vực khả dụng của bạn để đảm bảo độ trễ thấp nhất cho tất cả các khách hàng.
    • Và sau đó là các yêu cầu khác như thiết lập một chính sách quản lý dữ liệu phù hợp để đảm bảo việc truy cập dữ liệu được kiểm soát, cũng như hoàn toàn tuân thủ các quy định về dữ liệu địa phương (như GDPR).

Kết thúc

Go to Link