tuandht97
Senior Member
a có tài liệu tái hiện lại case này ko cho e xin vớiMình nghi là bạn này nghe lõm bõm ko xác định lại số với người pv, lại càng ko thấy thông tin về assumption này nọ.
1M total users với 1M total users cùng lúc nó khác nhau lắm. Thêm cả, cùng lúc ko bao giờ nghỉ hoặc cùng lúc trong 1 khoảng thời gian ngắn nó lại càng khác.
Hôm nọ mình có design 1 bài take-home test cho ny tập đi interview, 32M người dùng tổng cộng, thì tính toán sơ peak time tầm dc 130K concurrent requests liên tục trong 1 tiếng => 35 request per second. Con số này quá là bé cho 1 cái service cụ thể và cực kì dễ làm.
Kể cả 1M concurrent request trong 1 tiếng cũng chỉ có 277 RPS, cứ tính toán cẩn thận lại ra được lượng instances cần scale thôi (tầm 6 cho light workload service, 10-12 cho heavy workload service, etc.)
Cái sai của kì pv kia là hỏi quá dàn trải (backend-devops-frontend), gặp mình cũng ko trả lời dc. Mà cũng có khi bạn pv yếu quá rồi lại drama hoá cái kì pv lên, để ra vẻ nó quá thiếu hợp lí, và bạn trẻ kia pv rớt vì pv quá rộng, chứ k phải bản thân bạn kia kém.
Chứ xoáy vào 1M concurrent users em lại thấy quá bình thường.

cũng 3x nhưng chưa tới đầu 4. Pv khó hơn là thật, nhưng cơ hội cũng nhiều hơn, chỉ cần kiên nhẫn thì sẽ có được offer như ý thôi

và thằng phỏng vấn chưa chắc trả lời được câu hỏi mà nó đặt ra, tôi đoán ở đây là system của cty mà ứng viên đang pvan cũng đang có bài toán tương tự về perf test và người pv cố tình khai thác ứng viên senior để lấy thôgn tin thoi chứ chưa chắc tuyển thật ấy, phí công sức của người khác đi pv