Top 20+ câu hỏi phỏng vấn Software Architect phổ biến

Trong thị trường công nghệ ngày càng phát triển, vị trí Software Architect ngày càng trở nên quan trọng với vai trò thiết kế và định hướng các hệ thống phần mềm phức tạp. Để thành công trong buổi phỏng vấn Software Architect, ứng viên cần chuẩn bị kỹ lưỡng với các câu hỏi chuyên sâu về kiến thức phần mềm cũng như kỹ năng giải quyết vấn đề. Bài viết này sẽ cung cấp danh sách câu hỏi phỏng vấn Software Architect phổ biến, giúp bạn tự tin khẳng định năng lực trong buổi phỏng vấn tiếp theo.

Đọc bài viết này để biết rõ hơn về:

Tổng quan về Software Architect
Các câu hỏi phỏng vấn Software Architect về kiến thức chuyên môn
Các câu hỏi phỏng vấn Software Architect về tình huống

Tổng quan về vị trí Software Architect

Software Architect là một lập trình viên hoặc nhà phát triển phần mềm chịu trách nhiệm xác định các quy trình và công nghệ mà nhóm phát triển sẽ sử dụng. Ở vai trò này, bạn sẽ giải quyết các vấn đề liên quan đến mã nguồn và hợp tác với các chuyên gia khác để xây dựng hệ thống phần mềm có hiệu suất cao. Nhiệm vụ chính của bạn là tìm ra các giải pháp phần mềm phù hợp với mục tiêu kinh doanh và yêu cầu công nghệ của công ty.

Nhiệm vụ và trách nhiệm của Software Architect:

Gặp gỡ khách hàng, hiểu mục tiêu kinh doanh, xác định yêu cầu và thiết kế giải pháp phần mềm.
Dẫn dắt nhóm thiết kế và xây dựng ứng dụng theo kiến trúc đã đề ra.
Thảo luận với khách hàng về các cải tiến giúp tối ưu hóa quy trình kinh doanh hoặc phần mềm.
Lập kế hoạch phát triển nền tảng ứng dụng phù hợp với tình hình công ty và có khả năng mở rộng.
Làm việc với nhiều nhà phát triển và đảm bảo hoàn thành dự án đúng hạn.
Tương tác với các vai trò khác như kiểm thử viên và nhà phân tích kinh doanh.
Software Architect có thể làm việc trong nhiều ngành, từ sản xuất, tài chính đến phát triển phần mềm, theo hình thức tự do, hợp đồng hoặc toàn thời gian.

Một Software Architect chuyên nghiệp cần có hai loại kỹ năng: kỹ năng chuyên môn (hard skills) và kỹ năng mềm (soft skills). Cụ thể hơn:

Kỹ năng chuyên môn:

Thành thạo công nghệ cụ thể: Kiến thức vững về các công nghệ như AngularJS, Node.js, và JavaScript.
Hiểu biết về hệ sinh thái công nghệ: Kiến thức về các giải pháp công nghệ và khả năng chọn lựa phù hợp.
Kỹ năng về công nghệ đám mây: Am hiểu công nghệ đám mây để hỗ trợ doanh nghiệp chọn và triển khai công cụ phù hợp.
Kiến thức về kiến trúc phần mềm hiện đại: Thành thạo các mô hình và kiến trúc phần mềm như microservices và serverless.
Hiểu biết về miền kinh doanh và cơ sở dữ liệu: Hiểu rõ lĩnh vực kinh doanh và cơ sở dữ liệu để giải quyết vấn đề hiệu quả.

Kỹ năng mềm:

Kỹ năng lãnh đạo: Hướng dẫn, quản lý nhóm và giải quyết xung đột.
Kỹ năng giải quyết vấn đề: Xác định và giải quyết các vấn đề kỹ thuật.
Quản lý thời gian và đặt mục tiêu: Quản lý nhiều nhiệm vụ và đảm bảo dự án đi đúng hướng.
Kỹ năng giao tiếp: Giao tiếp rõ ràng với các bên liên quan và đội ngũ.
Tư duy sáng tạo: Tìm giải pháp sáng tạo để hỗ trợ sự phát triển của tổ chức.

Bạn có thể tham khảo chi tiết về vị trí này qua các bài viết:

Câu hỏi phỏng vấn Software Architect về kiến thức chuyên môn

Cluster là gì? Tầm quan trọng của Cluster

Cụm (cluster) là tập hợp các phần cứng được kết nối để đạt mục tiêu tính toán chung. Từ góc độ kiến trúc sư phần mềm, cụm giúp kết hợp các máy chủ và khối lượng công việc để tạo ra cơ sở hạ tầng hiệu quả cho tổ chức.

Cụm gồm nhiều máy vật lý hoặc ảo liên kết với nhau nhằm tận dụng tối đa tài nguyên. Khi thiết lập, cần cấu hình chính xác mạng, chính sách cân bằng tải và kế hoạch dung lượng để đạt hiệu suất tối ưu.

Hệ thống cluster trong kiến trúc phần mềm không chỉ liên quan đến phần cứng mà còn bao gồm nhiều nút (nodes) hoạt động cùng nhau trong một hệ thống phân tán để cung cấp:

Tính sẵn sàng cao (High Availability – HA): Đảm bảo dịch vụ hoạt động liên tục dù có sự cố ở một số nút.
Cân bằng tải (Load Balancing): Phân phối công việc đồng đều giữa các nút để tối ưu hiệu suất.
Khả năng mở rộng (Scalability): Cho phép mở rộng hệ thống dễ dàng bằng cách thêm các nút mới.

Clustering là công cụ quan trọng giúp kiến trúc sư phần mềm tổ chức dữ liệu hiệu quả hơn, chia nhỏ các tập dữ liệu phức tạp và tận dụng sức mạnh tính toán để xử lý nhanh chóng và chính xác.

Ngoài ra, clustering còn tăng cường bảo mật, khả năng mở rộng, giảm chi phí phần cứng và đảm bảo dự phòng khi hệ thống gặp sự cố, mang lại hiệu suất tối ưu cho nhiều ứng dụng.

Bạn hiểu gì về “KISS” và “DRY”? Chúng được áp dụng trong lĩnh vực kỹ sư phần mềm như thế nào?

Câu hỏi này đánh giá sự hiểu biết của ứng viên về các nguyên tắc thiết kế phần mềm cơ bản nhằm đảm bảo tính đơn giản và dễ bảo trì.

DRY (Don’t Repeat Yourself): Nguyên tắc này khuyến khích tránh lặp lại mã nguồn. Tập trung vào trừu tượng hóa và tái sử dụng giúp giảm mã trùng lặp, đơn giản hóa quá trình bảo trì và hạn chế sự không nhất quán.

KISS (Keep It Simple, Stupid): Thiết kế hệ thống đơn giản thường hiệu quả hơn thiết kế phức tạp. Sự đơn giản giúp dễ hiểu, giảm công việc bảo trì và hạn chế rủi ro sai sót.

Giải nghĩa về định lý CAP

Định lý CAP chỉ ra rằng các hệ thống máy tính phân tán chỉ có thể đảm bảo hai trong ba yếu tố sau:

Nhất quán (Consistency): Tất cả các nút trong hệ thống đều truy cập cùng một dữ liệu, ngay cả khi có cập nhật đồng thời.
Sẵn sàng (Availability): Mọi yêu cầu đều nhận được phản hồi, dù thành công hay thất bại.
Chịu phân vùng (Partition tolerance): Hệ thống vẫn duy trì hoạt động khi có sự gián đoạn trong kết nối giữa các nút.

Domain Driven Design (DDD) là gì?

Thiết kế theo miền (Domain Driven Design – DDD) là một kỹ thuật thiết kế hệ thống phức tạp, tập trung vào việc ánh xạ các hành động, quy trình, sự kiện và dữ liệu từ miền vấn đề vào các giải pháp công nghệ. Câu hỏi này nhằm đánh giá sự hiểu biết của ứng viên về triết lý DDD và tầm quan trọng của nó trong phát triển phần mềm.

Ngoài ra, DDD sử dụng Ngôn ngữ chung (Ubiquitous Language) giữa nhà phát triển và chuyên gia lĩnh vực để đảm bảo sự thống nhất trong giao tiếp. DDD cũng chia hệ thống thành các Bounded Contexts, giúp quản lý và phát triển độc lập từng phần của hệ thống, giảm thiểu phức tạp và hỗ trợ mở rộng.

Vậy nên, DDD ưu tiên miền kinh doanh, đảm bảo phần mềm phù hợp với ngữ cảnh và quy tắc của nó. Phương pháp này bao gồm việc sử dụng ngôn ngữ chung giữa nhà phát triển và chuyên gia (Ngôn ngữ phổ biến), phân chia miền thành các ngữ cảnh có thể quản lý (Bounded Contexts), và phân biệt giữa thực thể và đối tượng giá trị. DDD giúp cải thiện sự đồng bộ giữa công nghệ và nhu cầu kinh doanh trong các hệ thống phức tạp.

Khi nào bạn nên sử dụng microservices và khi nào nên sử dụng monolithic?

Kiến trúc microservices chia phần mềm thành các dịch vụ độc lập, mỗi dịch vụ có logic và cơ sở dữ liệu riêng. Điều này giúp quản lý độ phức tạp bằng cách tách nhiệm vụ thành các quy trình nhỏ hơn, mặc dù không làm giảm phức tạp tổng thể. Microservices thường đi cùng với DevOps để hỗ trợ phát hành liên tục và phản ứng nhanh với yêu cầu của người dùng.

Kiến trúc monolithic là mô hình phần mềm truyền thống, xây dựng như một đơn vị lớn với một cơ sở mã duy nhất. Việc cập nhật ứng dụng yêu cầu phải thay đổi toàn bộ ngăn xếp và triển khai phiên bản mới, làm cho việc cập nhật trở nên khó khăn và tốn thời gian. Mặc dù thuận tiện trong giai đoạn đầu dự án nhờ dễ quản lý mã nguồn và triển khai, kiến trúc monolithic có thể gặp khó khăn khi cần thay đổi hoặc mở rộng.

Khi chọn giữa kiến trúc monolithic và microservices, hãy cân nhắc các yếu tố sau:

Độ phức tạp của ứng dụng: Ứng dụng đơn giản có thể không cần đến microservices.
Kích thước đội ngũ: Các đội ngũ lớn có thể hưởng lợi từ sự tự chủ của microservices.
Yêu cầu mở rộng: Microservices phù hợp nếu các phần của ứng dụng có nhu cầu mở rộng khác nhau.
Tần suất triển khai: Microservices hỗ trợ việc triển khai cập nhật thường xuyên và độc lập.
Đa dạng công nghệ: Microservices cho phép sử dụng nhiều công nghệ và ngôn ngữ khác nhau.
Mức độ trưởng thành tổ chức: Đảm bảo đội ngũ của bạn có kỹ năng và công cụ để quản lý hệ thống phân tán.
Ngân sách và tài nguyên: Microservices yêu cầu đầu tư ban đầu cao hơn cho cơ sở hạ tầng.
Tăng trưởng tương lai: Bắt đầu với microservices có thể giúp tránh tái cấu trúc phức tạp sau này nếu ứng dụng dự kiến phát triển lớn.

Bạn sẽ đảm bảo scalability của hệ thống như thế nào?

Khả năng mở rộng (scalability) là khả năng của hệ thống để xử lý khối lượng công việc ngày càng tăng mà không giảm hiệu suất. Một hệ thống có khả năng mở rộng tốt có thể duy trì hoặc cải thiện hiệu suất và độ tin cậy khi khối lượng công việc hoặc phạm vi tăng lên, đảm bảo xử lý hiệu quả lượng người dùng, dữ liệu, hoặc yêu cầu tính toán gia tăng mà không cần thiết kế lại hoàn toàn.

Xây dựng ứng dụng web mở rộng hiệu quả bao gồm:

Chọn kiến trúc phù hợp: Sử dụng microservices hoặc thiết kế mô-đun để dễ dàng mở rộng và linh hoạt, thay vì monolithic. Với ứng dụng mới, có thể thử phương pháp kết hợp như dịch vụ “microlith” lớn hơn trước khi xác định mô hình tốt nhất.
Chọn công nghệ mở rộng: Lựa chọn ngôn ngữ lập trình, framework, và cơ sở dữ liệu có khả năng mở rộng và hiệu suất cao. Sử dụng công nghệ đám mây để mở rộng dễ dàng hơn.
Tận dụng cân bằng tải: Phân phối lưu lượng truy cập đến nhiều máy chủ để tránh quá tải và đảm bảo tính sẵn sàng.
Tối ưu hóa mã nguồn: Thường xuyên xem xét và cải thiện mã nguồn để nâng cao hiệu suất và giảm tắc nghẽn.
Theo dõi và phân tích: Sử dụng công cụ theo dõi hiệu suất để phát hiện và giải quyết vấn đề nhanh chóng.
Tự động hóa mở rộng: Áp dụng giải pháp mở rộng tự động dựa trên đám mây để điều chỉnh tài nguyên theo nhu cầu, tiết kiệm chi phí.

Bắt đầu với khả năng mở rộng từ sớm và liên tục điều chỉnh để đáp ứng yêu cầu của ứng dụng và người dùng.

Cho biết SOLID là gì?

Các nguyên tắc SOLID bao gồm năm nguyên tắc cơ bản dành cho các nhà kiến trúc phần mềm và phát triển:

Single responsibility (Trách nhiệm đơn): Mỗi lớp nên chỉ chịu trách nhiệm cho một phần cụ thể của ứng dụng.
Open/closed (Mở/đóng): Mô-đun hoặc lớp nên mở để mở rộng nhưng đóng để sửa đổi.
Liskov substitution (Thay thế Liskov): Khi sử dụng kế thừa, các đối tượng từ lớp cha hoặc lớp con phải hoạt động đúng như mong đợi.
Interface segregation (Phân tách giao diện): Các giao diện nên nhỏ gọn và chuyên biệt.
Dependency inversion (Đảo ngược phụ thuộc): Các lớp cao cấp không nên phụ thuộc vào các lớp thấp cấp, mà cả hai nên dựa vào các trừu tượng cấp cao.

Bạn thường sử dụng công cụ nào để kiểm tra mã phần mềm?

Công cụ kiểm thử được thiết kế để kiểm tra và xác minh phần mềm, giúp cải thiện chất lượng và phát hiện lỗi. Chúng hỗ trợ ghi lỗi, phân tích và thực hiện kiểm thử, đồng thời đánh giá chức năng, hiệu suất và bảo mật của phần mềm hoặc hệ thống.

Các công cụ này bao gồm nhiều loại kiểm thử như kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử giao diện và kiểm thử khả năng tiếp cận. Mỗi công cụ được tối ưu hóa cho các khía cạnh cụ thể của kiểm thử, giúp cung cấp chẩn đoán chi tiết và tinh giản quy trình phát triển.

Một số công cụ kiểm tra mã phần mềm phổ biến bạn có thể nhắc đến như:

Selenium: Selenium là công cụ kiểm thử tự động mã nguồn mở chỉ dùng cho ứng dụng web, không hỗ trợ kiểm thử desktop hay di động. Để kiểm thử ứng dụng gốc, có thể sử dụng Appium.
LoadRunner: LoadRunner là công cụ kiểm thử hiệu suất hàng đầu, nổi bật với uy tín và khả năng hỗ trợ nhiều công cụ và giao thức.
JMeter: JMeter của Apache là công cụ mã nguồn mở dùng cho kiểm thử hiệu suất, đơn vị và đột biến, với giao diện người dùng thân thiện và hỗ trợ nhiều loại kiểm thử.
TestRail: TestRail giúp quản lý và theo dõi toàn bộ quá trình kiểm thử qua các bảng điều khiển và số liệu thống kê, cung cấp cái nhìn thời gian thực về tiến trình QA.
Invicti: Invicti (trước đây là NetSparker) phát hiện lỗ hổng bảo mật trên trang web và ứng dụng web, hỗ trợ phát hiện các vấn đề bảo mật khi mở rộng.
SoapUI: SoapUI là công cụ mã nguồn mở dành cho kiểm thử chức năng và API, hỗ trợ các dịch vụ SOA, REST, JMS và AMF.
LambdaTest: LambdaTest là công cụ kiểm thử đa trình duyệt, cho phép kiểm tra ứng dụng web trên nhiều cấu hình trình duyệt và hỗ trợ kiểm thử đáp ứng và gỡ lỗi.
Appium: Appium là công cụ mã nguồn mở cho kiểm thử tự động trên các ứng dụng di động gốc, web di động và lai trên iOS, Android và Windows, với khả năng kiểm thử trên nhiều hệ thống.
JUnit: JUnit là framework kiểm thử đơn vị phổ biến cho Java, cho phép lập trình viên viết và thực hiện kiểm thử tự động. Nó giúp đảm bảo từng phần mã hoạt động như mong đợi, nâng cao chất lượng mã và giảm thiểu lỗi trong quá trình phát triển.
NUnit: NUnit là framework kiểm thử đơn vị dành cho .NET, cung cấp tính năng linh hoạt để viết và chạy các bài kiểm thử. Nó hỗ trợ tổ chức các kiểm thử theo nhóm, giúp quản lý và bảo trì mã dễ dàng hơn.
SonarQube: SonarQube là công cụ phân tích mã tĩnh, phát hiện lỗi, code smells và lỗ hổng bảo mật trong mã nguồn. Nó theo dõi chất lượng mã theo thời gian và tích hợp với các công cụ CI/CD để kiểm tra mã liên tục.
Jenkins: Jenkins là công cụ tự động hóa mã nguồn mở cho tích hợp liên tục (CI) và triển khai liên tục (CD). Nó tự động hóa quy trình xây dựng, kiểm thử và triển khai, giúp tăng tốc độ phát triển phần mềm.
GitLab: GitLab là giải pháp tích hợp và triển khai liên tục tích hợp sẵn trong GitLab. Nó tự động hóa quy trình phát triển phần mềm, từ kiểm thử đến triển khai, giúp rút ngắn thời gian đưa sản phẩm ra thị trường.

Cache stampede là gì? Điều gì tạo nên cache stampede?

Vấn đề Cache Stampede (hay còn gọi là Dogpile Problem) trong thiết kế hệ thống xảy ra khi hệ thống dựa vào bộ nhớ đệm để nâng cao hiệu suất nhưng gặp phải sự gia tăng đột ngột về nhu cầu. Điều này có thể dẫn đến việc hệ thống quá tải, làm suy giảm hiệu suất do tài nguyên backend bị quá tải.

Vấn đề cache stampede có thể xảy ra do một số nguyên nhân chính:

Hết hạn bộ nhớ đệm: Khi tài nguyên hết hạn và nhiều yêu cầu đến cùng lúc, tất cả đều thấy bộ nhớ đệm trống và tạo ra lỗi bộ nhớ đệm, dẫn đến quá tải backend.
Cạnh tranh cao: Nhiều yêu cầu đồng thời truy cập cùng một mục bộ nhớ đệm, làm tăng khả năng xảy ra cache stampede do tất cả cố gắng tái tạo bộ nhớ đệm đồng thời.
Vô hiệu hóa bộ nhớ đệm đồng bộ: Khi nhiều yêu cầu cố gắng vô hiệu hóa cùng một mục bộ nhớ đệm và chặn lẫn nhau, có thể dẫn đến sự gia tăng yêu cầu đột ngột.
Hết hạn dựa trên thời gian: Khoảng thời gian hết hạn bộ nhớ đệm ngắn có thể dẫn đến nhiều yêu cầu đồng thời khi bộ nhớ đệm hết hạn.
Vô hiệu hóa dựa trên sự kiện: Tần suất cao của các sự kiện kích hoạt việc vô hiệu hóa bộ nhớ đệm có thể gây ra lỗi bộ nhớ đệm đồng thời.
Điểm nóng bộ nhớ đệm: Các mục bộ nhớ đệm phổ biến khi hết hạn có thể dẫn đến quá tải nếu không có cơ chế xử lý sự gia tăng nhu cầu.

Back-pressure là gì?

Back-pressure là khái niệm trong kỹ thuật phần mềm dùng để quản lý hệ thống xử lý lượng dữ liệu lớn. Nó giúp duy trì dòng dữ liệu ổn định bằng cách phản hồi về tải hiện tại của hệ thống. Back-pressure giúp cân bằng lượng dữ liệu vào và ra, đảm bảo truyền dữ liệu liên tục giữa các thành phần mà không gặp sự cố.

Khi hệ thống gặp tải đột ngột, back-pressure tạo ra một “hàng đợi động”, giữ các tác vụ chờ xử lý cho đến khi tải giảm. Điều này giúp ngăn ngừa quá tải và sự cố bằng cách điều chỉnh lưu lượng dữ liệu một cách kiểm soát.

Bạn biết gì về “coupling” và “cohesion”?

Tính mô-đun và khả năng bảo trì của hệ thống phần mềm bị ảnh hưởng mạnh mẽ bởi các khái niệm như coupling và cohesion.

Coupling đo lường mức độ phụ thuộc giữa các module phần mềm; mức độ thấp hơn cho thấy các module độc lập hơn, giúp dễ dàng sửa đổi và hiểu biết hơn.

Cohesion chỉ sự liên kết giữa các trách nhiệm trong một module. Cohesion cao làm tăng tính mô-đun và khả năng tái sử dụng của các chức năng trong module đó.

Phân loại các kiểu kiểm tra hệ thống (System Test) và cho biết vì sao chúng quan trọng

Kiểm thử hệ thống (System Testing) là một phương pháp kiểm thử phần mềm nhằm kiểm tra toàn bộ chức năng và hiệu suất của hệ thống đã được tích hợp hoàn chỉnh. Nó xác định xem hệ thống có đáp ứng các yêu cầu đặt ra và sẵn sàng cho người dùng cuối hay chưa. Giai đoạn này diễn ra sau kiểm thử tích hợp và trước kiểm thử chấp nhận.

Phân loại System testing:

Performance Testing (Kiểm thử hiệu năng): Là loại kiểm thử nhằm đánh giá tốc độ, khả năng mở rộng, tính ổn định và độ tin cậy của ứng dụng hoặc phần mềm.
Load Testing (Kiểm thử tải): Được thực hiện để kiểm tra hành vi của hệ thống khi hoạt động dưới tải lớn.
Stress Testing (Kiểm thử áp lực): Dùng để đánh giá sự bền vững của hệ thống khi đối mặt với các tải thay đổi đột ngột.
Scalability Testing (Kiểm thử khả năng mở rộng): Đánh giá khả năng hệ thống xử lý khi thay đổi số lượng yêu cầu người dùng, đảm bảo ứng dụng có thể mở rộng hoặc thu hẹp một cách hiệu quả.

Kiểm thử hệ thống (system testing) đảm bảo hiệu suất toàn diện của hệ thống bằng cách kiểm tra các chức năng từ đầu đến cuối, bao gồm cả kiến trúc phần mềm và yêu cầu nghiệp vụ. Quá trình này giúp giảm thiểu lỗi và sự cố ngay cả sau khi sản phẩm đã được triển khai. Bằng cách so sánh dữ liệu giữa hệ thống cũ và mới, kiểm thử hệ thống giúp người dùng hiểu rõ hơn về sự khác biệt và lợi ích của các tính năng mới được bổ sung, từ đó cải thiện sự hiệu quả và ổn định của hệ thống.

Bạn đã từng tìm hiểu về YAGNI chưa? Giải thích rõ hơn về vấn đề này

YAGNI (viết tắt của You Aren’t Gonna Need It) là nguyên tắc khuyến khích các nhà phát triển không thêm tính năng hoặc chức năng vào hệ thống cho đến khi chúng thực sự cần thiết. Việc thêm các tính năng không cần thiết có thể làm tăng độ phức tạp, kéo dài thời gian phát triển và có nguy cơ tạo ra nhiều lỗi hơn. Thay vào đó, các nhà phát triển nên tập trung vào việc cung cấp giải pháp đơn giản nhất đáp ứng đúng yêu cầu hiện tại.

YAGNI có vai trò quan trọng trong việc giữ cho quá trình phát triển phần mềm hiệu quả và tập trung. Bằng cách chỉ thực hiện những tính năng cần thiết, các nhà phát triển có thể tiết kiệm thời gian, tài nguyên và giảm bớt độ phức tạp của hệ thống, từ đó tạo ra một mã nguồn dễ bảo trì hơn.

Tại sao lại sử dụng WebSocket thay cho HTTP?

HTTP (HyperText Transfer Protocol) là giao thức chính trong giao tiếp web, cho phép trao đổi dữ liệu mượt mà trên Internet. Nó dùng để truyền tải các tài liệu siêu văn bản như HTML và thiết lập các quy tắc và tiêu chuẩn cho các giao dịch, đảm bảo rằng các ứng dụng web có thể kết nối và truy cập được dễ dàng.

WebSockets là giao thức cho phép giao tiếp hai chiều và thời gian thực giữa khách hàng và máy chủ. Được phát triển để khắc phục các hạn chế của HTTP, đặc biệt trong các ứng dụng thời gian thực cần giao tiếp liên tục và hai chiều, WebSockets tạo ra một kết nối liên tục giữa khách hàng và máy chủ, giúp giao tiếp hiệu quả hơn so với giao thức yêu cầu-phản hồi của HTTP.

WebSocket được ưu tiên sử dụng thay cho HTTP bởi vì:

Cập nhật thời gian thực: WebSocket cho phép cập nhật thời gian thực bằng cách gửi thông tin từ máy chủ đến khách hàng mà không cần yêu cầu liên tục, giúp dữ liệu được truyền nhanh hơn và nâng cao trải nghiệm người dùng.
Giao tiếp hai chiều: WebSocket hỗ trợ giao tiếp đồng thời giữa dapp và mạng blockchain, cho phép gửi và nhận dữ liệu mọi lúc, tạo ra các ứng dụng tương tác và đồng bộ thời gian thực.
Giảm độ trễ và tải mạng: WebSocket giảm độ trễ bằng cách loại bỏ các xác nhận liên tục, giảm thiểu tải mạng và tăng tốc độ giao tiếp, làm cho ứng dụng phản hồi nhanh hơn.

Sự khác biệt giữa deadlock,livelock và starvation

Livelock xảy ra khi một yêu cầu về khóa độc quyền liên tục bị từ chối do các khóa chia sẻ chồng chéo gây cản trở lẫn nhau, khiến các quy trình không thể hoàn thành nhiệm vụ của mình.

Deadlock là tình trạng trong hệ điều hành khi một quy trình bị chặn chờ vì một quy trình khác đang giữ tài nguyên mà nó cần. Đây là vấn đề phổ biến trong môi trường đa xử lý khi nhiều quy trình chia sẻ tài nguyên độc quyền.

Starvation là tình trạng một quy trình không thể thường xuyên truy cập vào các tài nguyên chia sẻ cần thiết để hoàn thành nhiệm vụ, dẫn đến việc quy trình đó không thể tiến triển.

Đặc điểm	Livelock	Deadlock	Starvation
Định nghĩa	Hai hoặc nhiều quy trình liên tục thay đổi trạng thái của chúng theo phản hồi từ trạng thái của các quy trình khác, nhưng không tiến triển.	Hai hoặc nhiều quy trình chờ đợi nhau giải phóng tài nguyên, tạo ra tình trạng đứng yên.	Một quy trình không thể tiếp cận tài nguyên cần thiết do các quy trình khác chiếm giữ tài nguyên đó.
Nguyên nhân	Phối hợp kém giữa các quy trình, thiếu đồng bộ hóa hợp lý.	Quản lý tài nguyên kém và phối hợp giữa các quy trình, nhiều quy trình truy cập tài nguyên chia sẻ cùng lúc.	Các quy trình dài hạn chiếm giữ tài nguyên, phân bổ tài nguyên không hợp lý, thời gian xử lý không đủ.
Kết quả	Không có sự tiến triển, thay đổi trạng thái liên tục, giảm hiệu suất.	Các quy trình bị chặn, giảm hiệu suất, có thể gây ra sự cố hệ thống.	Quy trình bị trì hoãn hoặc bị chặn, giảm hiệu suất, có thể gây ra sự cố hệ thống.
Giải pháp	Sử dụng các phương pháp như phá vỡ đối xứng, ngẫu nhiên, và thiết lập thời gian chờ.	Sử dụng các phương pháp như phát hiện và phục hồi, phòng ngừa, và tránh tắc nghẽn.	Sử dụng lập lịch ưu tiên, lão hóa, và phân bổ tài nguyên.

Câu hỏi phỏng vấn Software Architect về tình huống

Nếu công ty muốn xây dựng một danh mục trực tuyến, bạn sẽ thực hiện những bước nào để thiết kế nó?

Nhà tuyển dụng cũng muốn đảm bảo rằng bạn có khả năng nhận diện nhu cầu cụ thể của tổ chức và lập kế hoạch chiến lược để đạt được kết quả thành công. Hãy dùng câu trả lời của bạn để thể hiện hiểu biết của bạn về công ty ứng tuyển và cách bạn có thể áp dụng thông tin này để triển khai danh mục trực tuyến hiệu quả.

Ví dụ câu trả lời:

Theo như tôi hiểu về tổ chức, danh mục trực tuyến sẽ cần một danh sách tổng hợp các phòng ban để cung cấp các danh mục sản phẩm theo từng loại.

Ví dụ, đối với phòng ‘phụ tùng và linh kiện động cơ’, tôi sẽ tạo một danh mục phụ với các trang sản phẩm cho từng mặt hàng trong kho liên quan. Trong mỗi trang sản phẩm, tôi sẽ thiết lập các phân mục nhỏ hơn dựa trên thông số kỹ thuật như màu sắc và kích cỡ. Tùy theo cấu trúc giá và quy trình thanh toán trực tuyến, tôi sẽ triển khai mã hóa tiêu chuẩn để đảm bảo an toàn trong cổng thanh toán của danh mục.

Trường hợp bạn phát hiện ra lỗ hổng bảo mật trong hệ thống, bạn làm sao để khắc phục nhanh chóng mà không ảnh hưởng đến người dùng?

Câu hỏi này nhằm đánh giá khả năng xử lý sự cố cũng như khả năng đưa ra quyết định nhanh chóng và không gây ảnh hưởng đến người dùng xuyên suốt quá trình xử lý.

Bạn có thể trả lời câu hỏi này như sau:

Khi phát hiện lỗ hổng bảo mật, việc đầu tiên tôi làm là đánh giá mức độ nghiêm trọng và phạm vi ảnh hưởng của lỗ hổng đó. Tôi sẽ xem xét các yếu tố sau:

Mức độ nghiêm trọng: Lỗ hổng có thể dẫn đến việc mất dữ liệu, chiếm quyền điều khiển hệ thống hay chỉ là một lỗ hổng tiềm ẩn?
Phạm vi ảnh hưởng: Lỗ hổng ảnh hưởng đến module nào, hệ thống con nào và có thể lan rộng ra toàn bộ hệ thống hay không?
Khả năng khai thác: Lỗ hổng có dễ bị khai thác hay không, và khả năng kẻ tấn công đã khai thác nó đến đâu?

Sau khi đánh giá, tôi sẽ tiến hành các bước sau:

Thông báo và phối hợp:

Thông báo cho đội ngũ: Thông báo ngay cho đội ngũ phát triển, bảo mật và vận hành để cùng nhau đưa ra giải pháp.
Thông báo cho người dùng (nếu cần): Nếu lỗ hổng có thể gây ảnh hưởng trực tiếp đến người dùng, tôi sẽ thông báo cho họ và đưa ra các khuyến cáo cần thiết.

Xây dựng kế hoạch khắc phục:

Ngăn chặn tạm thời: Áp dụng các biện pháp tạm thời để ngăn chặn lỗ hổng bị khai thác, ví dụ như chặn truy cập đến module bị ảnh hưởng, tăng cường kiểm soát truy cập.
Phát triển bản vá: Phân tích nguyên nhân gốc rễ của lỗ hổng và phát triển bản vá để khắc phục triệt để. Trong quá trình này, tôi sẽ ưu tiên các giải pháp không làm ảnh hưởng đến tính năng hiện tại của hệ thống.
Kiểm thử kỹ lưỡng: Thực hiện kiểm thử kỹ lưỡng bản vá trên môi trường thử nghiệm để đảm bảo không gây ra các vấn đề mới và lỗ hổng mới.

Triển khai bản vá:

Lên kế hoạch triển khai: Lên kế hoạch triển khai bản vá một cách an toàn và hiệu quả, có thể triển khai theo từng giai đoạn hoặc áp dụng phương pháp canary release.
Giám sát: Theo dõi chặt chẽ hệ thống sau khi triển khai bản vá để phát hiện và khắc phục kịp thời các vấn đề phát sinh.

Cập nhật tài liệu và quy trình:

Cập nhật tài liệu: Cập nhật tài liệu kỹ thuật, hướng dẫn sử dụng và các chính sách bảo mật để phản ánh những thay đổi.
Điều chỉnh quy trình: Điều chỉnh quy trình phát triển phần mềm để ngăn chặn các lỗ hổng tương tự xuất hiện trong tương lai, chẳng hạn như áp dụng các phương pháp kiểm thử bảo mật, code review chặt chẽ.

Ngoài ra, với tư cách là một Software Architect, tôi sẽ đặc biệt chú trọng đến các yếu tố sau:

Thiết kế hệ thống an toàn: Áp dụng các nguyên tắc thiết kế bảo mật ngay từ đầu để giảm thiểu rủi ro.
Xây dựng văn hóa bảo mật: Tạo ra một văn hóa bảo mật trong đội ngũ, khuyến khích mọi người báo cáo các lỗ hổng và tham gia vào quá trình bảo đảm an toàn.
Đầu tư vào các công cụ và giải pháp bảo mật: Sử dụng các công cụ quét lỗ hổng, hệ thống phát hiện xâm nhập (IDS), hệ thống ngăn chặn xâm nhập (IPS) để tăng cường bảo mật cho hệ thống.

Một trong những yêu cầu của khách hàng là xây dựng một kế hoạch dự phòng cho hệ thống trong trường hợp thảm họa (disaster recovery). Bạn sẽ thực hiện kế hoạch này như thế nào?

Để xây dựng một kế hoạch dự phòng thảm họa cho hệ thống, việc thực hiện theo từng bước chi tiết sẽ giúp đảm bảo an toàn và tính liên tục của hệ thống trong các tình huống không mong muốn.

Đánh giá rủi ro: Trước hết, việc phân tích toàn bộ hệ thống để xác định các rủi ro tiềm ẩn là cần thiết. Các rủi ro có thể bao gồm mất dữ liệu, tấn công mạng, hoặc hỏng hóc phần cứng. Hiểu rõ mức độ ưu tiên của từng thành phần giúp xác định các bộ phận quan trọng cần được bảo vệ đầu tiên trong trường hợp thảm họa.
Xác định mục tiêu khôi phục (RPO và RTO): Việc thiết lập các mục tiêu khôi phục là một phần quan trọng trong kế hoạch. RPO (Recovery Point Objective) chỉ ra lượng dữ liệu tối đa mà hệ thống có thể chấp nhận mất đi trong thời gian xảy ra sự cố, trong khi RTO (Recovery Time Objective) xác định thời gian tối đa mà hệ thống cần để khôi phục hoàn toàn.
Triển khai chiến lược sao lưu dữ liệu: Một chiến lược sao lưu dữ liệu hiệu quả giúp giảm thiểu nguy cơ mất mát thông tin quan trọng. Việc sao lưu có thể được thực hiện hàng ngày hoặc thậm chí theo thời gian thực và cần lưu trữ tại nhiều vị trí khác nhau, chẳng hạn như trên đám mây hoặc trung tâm dữ liệu dự phòng để đảm bảo dữ liệu luôn an toàn.
Xây dựng hệ thống dự phòng: Thiết lập các hệ thống Failover và Failback để đảm bảo khả năng chuyển đổi linh hoạt khi một trung tâm dữ liệu gặp sự cố. Hệ thống dự phòng này có thể được phân tán tại nhiều vị trí địa lý khác nhau để đảm bảo tính liên tục của dịch vụ.
Kiểm thử kế hoạch định kỳ: Sau khi hoàn tất kế hoạch, việc kiểm tra định kỳ rất quan trọng. Điều này bao gồm các bài kiểm thử giả lập để đánh giá khả năng khôi phục của hệ thống và đảm bảo rằng hệ thống có thể đáp ứng các mục tiêu RPO và RTO đã đề ra.
Tài liệu hóa và hướng dẫn chi tiết: Cuối cùng, việc tài liệu hóa toàn bộ kế hoạch dự phòng thảm họa giúp mọi thành viên trong nhóm kỹ thuật và khách hàng đều hiểu rõ quy trình. Đồng thời, hướng dẫn chi tiết sẽ giúp đảm bảo quá trình khôi phục diễn ra suôn sẻ trong tình huống khẩn cấp.

Bằng cách thực hiện kế hoạch dự phòng thảm họa theo các bước trên, hệ thống của bạn sẽ được bảo vệ tốt hơn trước những rủi ro tiềm ẩn, đồng thời giảm thiểu thiệt hại và đảm bảo tính liên tục của dịch vụ.

Số lượng người dùng của hệ thống đang tăng trưởng nhanh chóng và bạn cần đảm bảo hệ thống có khả năng mở rộng quy mô (scalability). Bạn sẽ làm gì để chuẩn bị cho việc này?

Để đảm bảo hệ thống có khả năng mở rộng quy mô khi số lượng người dùng tăng trưởng nhanh chóng, việc lập kế hoạch và chuẩn bị kỹ lưỡng là điều cần thiết. Dưới đây là các bước tôi sẽ thực hiện:

Đánh giá hệ thống hiện tại: Trước tiên, tôi sẽ phân tích kỹ lưỡng kiến trúc hệ thống hiện tại để hiểu rõ các giới hạn về hiệu suất, điểm nghẽn (bottlenecks) và khả năng chịu tải của hệ thống. Điều này giúp xác định các khu vực cần nâng cấp để hỗ trợ việc mở rộng quy mô.
Áp dụng kiến trúc Microservices: Nếu hệ thống hiện tại đang sử dụng kiến trúc monolithic, tôi sẽ cân nhắc chuyển sang kiến trúc microservices. Microservices giúp phân tán các thành phần của hệ thống thành các dịch vụ độc lập, từ đó có thể mở rộng từng dịch vụ riêng biệt dựa trên nhu cầu sử dụng. Điều này giúp giảm tải và tăng khả năng xử lý của hệ thống mà không cần phải mở rộng toàn bộ hệ thống cùng lúc.
Sử dụng cơ sở hạ tầng tự động mở rộng (Auto-scaling): Tôi sẽ triển khai các giải pháp Auto-scaling trên hạ tầng đám mây hoặc máy chủ vật lý. Điều này cho phép hệ thống tự động thêm hoặc giảm số lượng máy chủ dựa trên nhu cầu sử dụng thực tế. Các nền tảng như AWS, Azure, hoặc Google Cloud cung cấp tính năng này, giúp đảm bảo hiệu suất ổn định ngay cả khi lượng người dùng tăng đột biến.
Tối ưu hóa cơ sở dữ liệu: Việc mở rộng quy mô cần đặc biệt chú trọng đến cơ sở dữ liệu. Tôi sẽ cân nhắc sử dụng các kỹ thuật như **sharding** để phân chia cơ sở dữ liệu thành các phần nhỏ hơn, hay sử dụng **caching** như Redis hoặc Memcached để giảm tải trực tiếp lên cơ sở dữ liệu, tăng tốc độ xử lý và cải thiện hiệu suất.
Sử dụng cân bằng tải (Load Balancing): Để đảm bảo rằng không một máy chủ nào bị quá tải, tôi sẽ triển khai cân bằng tải (load balancing). Cân bằng tải sẽ phân phối các yêu cầu từ người dùng đến nhiều máy chủ khác nhau, giúp tối ưu hóa hiệu suất và giảm thiểu rủi ro hệ thống bị quá tải tại một điểm.
Kiểm tra khả năng mở rộng: Sau khi thực hiện các thay đổi, tôi sẽ tiến hành stress testing và load testing để kiểm tra khả năng chịu tải của hệ thống khi số lượng người dùng tăng mạnh. Các bài kiểm tra này giúp xác định điểm giới hạn của hệ thống và đưa ra giải pháp khắc phục kịp thời trước khi triển khai.
Giám sát và cải thiện liên tục: Cuối cùng, tôi sẽ thiết lập các công cụ giám sát hiệu suất như Prometheus, Grafana hoặc ELK Stack để theo dõi liên tục các chỉ số quan trọng như CPU, RAM, lưu lượng mạng và hiệu suất cơ sở dữ liệu. Nhờ đó, tôi có thể phát hiện sớm các vấn đề và tối ưu hóa hệ thống một cách chủ động.

Với những bước chuẩn bị và tối ưu hóa trên, hệ thống sẽ được đảm bảo có khả năng mở rộng linh hoạt, đáp ứng được nhu cầu ngày càng tăng của người dùng.

Một khách hàng yêu cầu bạn tối ưu hóa hệ thống của họ cho một sự kiện lớn sắp tới, nhưng thời gian rất hạn chế. Bạn sẽ ưu tiên những gì và thực hiện các bước nào để đảm bảo hệ thống hoạt động ổn định?

Tình huống này đòi hỏi một sự cân bằng giữa tốc độ và chất lượng. Dưới đây là một số ưu tiên và bước đi mà tôi sẽ thực hiện:

Đánh giá nhanh tình hình:

Hiểu rõ hệ thống: Tìm hiểu cấu trúc, công nghệ, điểm nghẽn hiện tại của hệ thống.
Xác định mục tiêu: Xác định rõ các chỉ số cần đạt được (ví dụ: số lượng người dùng đồng thời, tốc độ phản hồi,…) và các điểm cần cải thiện.
Phân tích log: Kiểm tra log hệ thống để tìm ra các lỗi thường gặp, điểm gây tắc nghẽn.

Ưu tiên các biện pháp tối ưu nhanh:

Tối ưu hóa cơ sở dữ liệu:
- Indexing: Tạo index cho các cột thường xuyên được truy vấn.
- Query optimization: Tối ưu hóa các câu truy vấn SQL, hạn chế các truy vấn phức tạp.
- Caching: Sử dụng cache để lưu trữ dữ liệu thường xuyên truy cập.
Tối ưu hóa mã:
- Profile code: Xác định các đoạn mã chạy chậm và tối ưu hóa chúng.
- Minify và combine files: Giảm kích thước file CSS, JavaScript.
- Lazy loading: Chỉ tải các tài nguyên khi cần thiết.

Cấu hình server:

Tăng tài nguyên: Tăng RAM, CPU nếu cần thiết.
Điều chỉnh cấu hình: Điều chỉnh các tham số của server (ví dụ: số lượng kết nối đồng thời, thời gian timeout).
CDN: Sử dụng mạng phân phối nội dung (CDN) để tăng tốc độ tải trang.

Giảm thiểu rủi ro:

Thử nghiệm A/B: Thử nghiệm các thay đổi nhỏ trước khi triển khai rộng rãi.
Rollback: Chuẩn bị sẵn kế hoạch rollback nếu có sự cố xảy ra.
Giám sát chặt chẽ: Sử dụng các công cụ giám sát để theo dõi hiệu suất hệ thống trong thời gian thực.

Phân công công việc:

Phân công rõ ràng: Phân công nhiệm vụ cho từng thành viên trong nhóm.
Ưu tiên các tác vụ: Xác định các tác vụ quan trọng nhất và thực hiện trước.
Communicate: Liên tục cập nhật thông tin cho các thành viên trong nhóm.

Tối đa hóa hiệu quả:

Automation: Tự động hóa các công việc lặp đi lặp lại.
Công cụ: Sử dụng các công cụ hỗ trợ như profiling tools, load testing tools.
Continuous integration/continuous deployment (CI/CD): Áp dụng CI/CD để nhanh chóng triển khai các thay đổi.

Tóm lại, để tối ưu hóa hệ thống trong thời gian ngắn, cần có sự kết hợp giữa kiến thức chuyên môn, kinh nghiệm và khả năng làm việc dưới áp lực cao. Việc ưu tiên các biện pháp mang lại hiệu quả nhanh chóng, giảm thiểu rủi ro và liên tục theo dõi, đánh giá là vô cùng quan trọng.

Hệ thống của bạn phải hoạt động trên cơ sở hạ tầng với tài nguyên hạn chế (CPU, RAM). Bạn sẽ tối ưu hóa hệ thống thế nào để đảm bảo hiệu suất mà không vượt quá giới hạn tài nguyên?

Khi hệ thống phải hoạt động trên cơ sở hạ tầng với tài nguyên hạn chế như CPU và RAM, việc tối ưu hóa là yếu tố then chốt để đảm bảo hiệu suất mà không vượt quá giới hạn tài nguyên. Để làm điều này, tôi sẽ thực hiện một số bước như sau:

Tối ưu hóa mã nguồn: Bước đầu tiên là tối ưu hóa mã nguồn của hệ thống. Tôi sẽ đảm bảo rằng các đoạn mã được viết tối giản, hiệu quả và không gây lãng phí tài nguyên. Những công cụ như profiling giúp xác định các đoạn mã tiêu tốn nhiều CPU và RAM, từ đó tối ưu lại thuật toán hoặc triển khai các phương pháp xử lý song song khi phù hợp.
Quản lý hiệu quả bộ nhớ (Memory Management): Tôi sẽ tập trung vào việc quản lý bộ nhớ một cách chặt chẽ bằng cách sử dụng các công nghệ như pooling, lazy loading, và caching để giảm thiểu việc sử dụng RAM. Bộ nhớ cache như Redis hoặc Memcached có thể được tận dụng để giảm thiểu việc truy xuất dữ liệu từ cơ sở dữ liệu và giảm tải trên hệ thống.
Sử dụng kiến trúc microservices: Chuyển đổi sang kiến trúc microservices có thể giúp hệ thống phân tán tải công việc một cách hiệu quả. Mỗi microservice có thể được triển khai độc lập với tài nguyên được giới hạn, giúp phân bổ CPU và RAM hợp lý cho từng chức năng. Điều này giúp ngăn chặn một thành phần tiêu tốn quá nhiều tài nguyên ảnh hưởng đến các thành phần khác.
Triển khai các chiến lược cân bằng tải (Load Balancing): Tôi sẽ sử dụng các giải pháp cân bằng tải (load balancing) để phân phối yêu cầu từ người dùng một cách hợp lý giữa các máy chủ. Điều này giúp ngăn ngừa tình trạng một máy chủ bị quá tải trong khi các máy chủ khác chưa tận dụng hết tài nguyên.
Tối ưu hóa cơ sở dữ liệu: Cơ sở dữ liệu thường tiêu tốn nhiều tài nguyên CPU và RAM. Do đó, tôi sẽ tối ưu hóa các truy vấn cơ sở dữ liệu, sử dụng chỉ mục (indexing) và kỹ thuật sharding để giảm thiểu khối lượng công việc xử lý tại một điểm. Ngoài ra, việc sử dụng caching để lưu trữ các kết quả truy vấn phổ biến cũng giúp giảm thiểu việc truy xuất dữ liệu liên tục từ cơ sở dữ liệu chính.
Quản lý các tác vụ nền (Background Tasks): Tôi sẽ đẩy các tác vụ không cần thiết phải thực hiện ngay lập tức sang các tiến trình nền, sử dụng các hệ thống message queue như RabbitMQ hoặc Kafka để xử lý theo thứ tự ưu tiên. Điều này giúp giải phóng tài nguyên cho các tác vụ quan trọng và giảm thiểu áp lực lên CPU và RAM trong thời gian cao điểm.
Sử dụng kiến trúc sự kiện (Event-driven Architecture): Sử dụng kiến trúc dựa trên sự kiện (Event-driven Architecture) giúp hệ thống chỉ xử lý khi có sự kiện xảy ra, thay vì chạy liên tục và lãng phí tài nguyên. Điều này đặc biệt hữu ích khi tài nguyên bị giới hạn.
Theo dõi và giám sát: Cuối cùng, tôi sẽ triển khai các công cụ giám sát như Prometheus hoặc New Relic để theo dõi việc sử dụng tài nguyên của hệ thống. Dựa vào dữ liệu này, tôi có thể điều chỉnh các cấu hình, cân bằng tài nguyên và cải thiện hiệu suất hệ thống theo thời gian.

Những phương pháp này giúp hệ thống hoạt động hiệu quả trên nền tảng với tài nguyên hạn chế, giảm thiểu việc lãng phí tài nguyên trong khi vẫn đảm bảo hiệu suất tốt nhất có thể.

Tổng kết câu hỏi phỏng vấn Software Architect

Vừa rồi, chúng ta đã đi qua 20+ câu hỏi phỏng vấn Software Architect giúp bạn tăng khả năng trúng tuyển. Hy vọng, những câu hỏi ITviec nêu trên có thể giúp bạn có sự chuẩn bị tốt nhất cho buổi phỏng vấn sắp tới. Chúc bạn gặp nhiều may mắn và sẽ thành công trong việc có được công việc mong muốn.