1. Có thể thay thế POST thành GET và ngược lại không? (HTTP method)
   1. Post hay get chỉ là định nghĩa trong rfc của http và hoàn toàn có thể hoán đổi cho nhau đc. Tuy nhiên về mặt bảo mật get và post ko được phép hoán đổi cho nhau. Query và params của Get gần như log ở mọi hệ thống log nó đi qua ( kể cả reverse proxy ) vì thế nên với các request xác thực và phân quyền không được phép dùng get kể cả là giao tiếp giữa frontend severside render với backend

• GET thường được sử dụng để yêu cầu dữ liệu từ server và không làm thay đổi trạng thái server. Trong khi đó, POST được sử dụng để gửi dữ liệu tới server để xử lý, thường làm thay đổi trạng thái server. GET nên idempotent (không thay đổi trạng thái), trong khi POST không cần idempotent và có thể làm thay đổi trạng thái hoặc dữ liệu.

1. Map/Dict bên trong hoạt động như thế nào? (programming language)
   • Map (hoặc Dictionary) là cấu trúc dữ liệu lưu trữ các cặp khóa-giá trị (key-value pairs). Khi thêm một cặp khóa-giá trị, khóa được băm (hashed) để xác định vị trí của giá trị trong một bảng băm (hash table). Khi truy xuất giá trị, khóa được băm lại và vị trí trong bảng băm được tìm ra. Điều này giúp cho việc truy xuất và lưu trữ dữ liệu có độ phức tạp trung bình là O(1).
2. Load balancer là gì? Trong context API, dùng API Gateway thay thế được không?
   • Load balancer phân phối lưu lượng mạng hoặc ứng dụng đến một số server backend để đảm bảo không một server nào bị quá tải, cải thiện hiệu suất và độ tin cậy của ứng dụng.
   • API Gateway có thể bao gồm chức năng của một load balancer, nhưng nó còn cung cấp nhiều tính năng khác như xác thực, quản lý API, và giám sát. Do đó, API Gateway có thể thay thế load balancer trong nhiều trường hợp và thường là lựa chọn tốt hơn cho việc quản lý API toàn diện.
3. Những cách để truyền tải response từ backend về cho frontend nhanh và tối ưu
   • Caching: Sử dụng caching để giảm tải server và tăng tốc độ phản hồi bằng cách lưu trữ tạm thời dữ liệu thường được yêu cầu.
   • Gzip/Compression: Nén dữ liệu phản hồi để giảm kích thước truyền tải qua mạng.
   • Content Delivery Network (CDN): Sử dụng CDN để phân phối nội dung tĩnh từ các server gần với người dùng cuối.
   • Asynchronous Requests: Sử dụng các yêu cầu không đồng bộ (AJAX, fetch API) để tải dữ liệu mà không làm gián đoạn giao diện người dùng.
   • Minimize Data: Chỉ truyền tải những dữ liệu cần thiết nhất, giảm bớt các thông tin không cần thiết trong response.

Có bao nhiêu cách giao tiếp giữa các microservices nêu qua về ưu nhược điểm của từng cách thức giao tiếp?

Giao tiếp giữa các microservices có thể thực hiện thông qua nhiều cách khác nhau. Dưới đây là một số phương pháp phổ biến cùng với ưu và nhược điểm của từng cách:

1. HTTP/REST
   • Ưu điểm:
     • Đơn giản, dễ triển khai và sử dụng.
     • Dựa trên các phương thức HTTP chuẩn (GET, POST, PUT, DELETE).
     • Có thể dễ dàng đọc và gỡ lỗi.
   • Nhược điểm:
     • Giao tiếp đồng bộ, có thể gây ra vấn đề về hiệu suất và độ trễ.
     • Không phải lúc nào cũng phù hợp với các yêu cầu giao tiếp phức tạp.
2. gRPC
   • Ưu điểm:
     • Hiệu suất cao, hỗ trợ giao tiếp đồng bộ và không đồng bộ.
     • Sử dụng giao thức HTTP/2, giúp tối ưu hóa băng thông và độ trễ.
     • Hỗ trợ tự động sinh mã client và server từ định nghĩa giao diện (Protobuf).
   • Nhược điểm:
     • Phức tạp hơn HTTP/REST, cần học cách sử dụng Protobuf.
     • Hỗ trợ không rộng rãi bằng HTTP/REST.
3. Message Queue (RabbitMQ, Kafka, SQS, v.v.)
   • Ưu điểm:
     • Hỗ trợ giao tiếp không đồng bộ, giúp tách biệt các thành phần và giảm tải hệ thống.
     • Có khả năng chịu lỗi cao, đảm bảo tin nhắn được giao đúng đắn.
     • Thích hợp cho các tác vụ cần xử lý hàng loạt hoặc cần độ tin cậy cao.
   • Nhược điểm:
     • Phức tạp trong việc triển khai và quản lý.
     • Có thể cần thời gian để làm quen và thiết lập hệ thống message queue.
4. GraphQL
   • Ưu điểm:
     • Cho phép client yêu cầu chính xác dữ liệu cần thiết, giảm bớt dữ liệu không cần thiết.
     • Hỗ trợ các yêu cầu phức tạp và linh hoạt.
     • Tích hợp tốt với các ứng dụng frontend hiện đại.
   • Nhược điểm:
     • Có thể phức tạp hơn REST trong việc thiết kế và triển khai.
     • Có thể cần thêm công sức trong việc bảo mật và quản lý quyền truy cập.
5. Event-Driven Communication (Event Sourcing, CQRS)
   • Ưu điểm:
     • Hỗ trợ giao tiếp không đồng bộ, phù hợp cho các hệ thống phản ứng nhanh và linh hoạt.
     • Giúp ghi lại lịch sử các sự kiện, dễ dàng truy vết và phân tích.
   • Nhược điểm:
     • Phức tạp trong thiết kế và triển khai.
     • Cần quản lý và lưu trữ sự kiện, có thể tốn kém tài nguyên.
6. Socket-based Communication (WebSockets, ZeroMQ)
   • Ưu điểm:
     • Hỗ trợ giao tiếp hai chiều theo thời gian thực, thích hợp cho các ứng dụng cần cập nhật liên tục.
     • Hiệu suất cao, độ trễ thấp.
   • Nhược điểm:
     • Phức tạp trong việc thiết kế và duy trì kết nối.
     • Có thể cần thêm các biện pháp bảo mật để bảo vệ dữ liệu truyền tải.

Các khái niệm:

Webhook, WebSockets, Pub/Sub và Polling

1. Webhook
   • Ưu điểm:
     • Chủ động gửi dữ liệu từ server tới client khi có sự kiện xảy ra.
     • Tiết kiệm tài nguyên vì không cần liên tục kiểm tra trạng thái.
   • Nhược điểm:
     • Cần cấu hình đúng endpoint để nhận dữ liệu.
     • Phụ thuộc vào khả năng tin cậy của bên gửi webhook.
2. WebSockets
   • Ưu điểm:
     • Kết nối hai chiều theo thời gian thực, cho phép cập nhật liên tục.
     • Hiệu suất cao, độ trễ thấp.
   • Nhược điểm:
     • Phức tạp hơn trong việc thiết kế và duy trì kết nối.
     • Có thể cần thêm các biện pháp bảo mật để bảo vệ dữ liệu truyền tải.
3. Pub/Sub (Publish/Subscribe)
   • Ưu điểm:
     • Hỗ trợ giao tiếp không đồng bộ, phù hợp cho các hệ thống phản ứng nhanh.
     • Cho phép nhiều subscriber nhận dữ liệu cùng một lúc.
   • Nhược điểm:
     • Phức tạp trong việc thiết kế và quản lý hệ thống.
     • Cần đảm bảo tính nhất quán và độ tin cậy của tin nhắn.
4. Polling
   • Ưu điểm:
   • Nhược điểm:

SQL Isolations