Theo mình còn một cách phân loại user nữa đó là theo mức độ engage. Hệ thống đánh trọng số đối với các action khác nhau của user như xem, like, comment để tính mức độ engage với một account. Khi account đó đăng bài thì ưu tiên xử lý update timeline cho ông nào chỉ số engage cao trước vì mấy ông đó quan tâm thật sự.
Từ thiết kế, Anh Huy làm chi tiết thêm cách tạo ra mấy cái cục, cách kết nối mấy cục đó bằng code đi anh ❤❤🎉🎉🎉🎉 Tkss anh, các videos rất tuyệt vời 🎉🎉🎉🎉🎉🎉
Em rất thích xem video thiết kế hệ thống kiểu này, nhưng mà không biết từ thiết kế ra code thực tế như thế nào, mong anh Huy làm chi tiết thêm.. ❤❤ Tks anh 🎉🎉🎉
Quá hay luôn anh! Qua video của anh cùng với buổi live về "Chiến lược Scale Database" em mới thấy sai lầm của bản thân đã gặp phải khi thiết kế một hệ thống (dù nhỏ) là cố gắng đưa ra một mô hình phức tạp ngay từ đầu thay vì làm nó đơn giản đáp ứng đủ nhu cầu, đồng thời có thể mở rộng về sau khi đã có đủ lượng người dùng và quan trọng là có doanh thu, lợi nhuận.
Mình có xem 1 vid seminar của 1 anh engineer chia sẻ về thiết kế của twitter, thì gần như họ chỉ tương tác với cache, còn database chỉ để lưu trữ thôi. Còn về việc giảm tải bằng cách chia theo status của user thế thì cũng có khả năng, nhưng mà họ sẽ read các bài viết mới nhất của celeb họ follow từ cache luôn, nghĩa là mỗi khi celeb post bài họ sẽ save vào db để lưu trữ + sync qua cache của họ để phục vụ các request.
Hầu như 100% ông lớn MXH nào cũng ưu tiên dùng cache. cache hit đạt 95-96% là bình thường. MXH nào cũng quan trọng thu hút user cho nên phân loại theo tương tác là quan trọng nhất. Còn việc video này giải quyết nó chỉ là 1 phần nhỏ. Nếu giải quyết bài toán phân loại theo user tương tác nhiều khi họ bỏ qua luôn case của video đang giải quyết
Bài chia sẻ của bạn rất hay và bổ ích, chỉ một góp ý nhỏ là bạn nói chuyện đừng cương quá, người nghe sẽ cảm thấy rất mệt. Chúc bạn sức khoẻ và ra nhiều video bổ ích nữa nhé 😁
uh, cách tiếp cận này lúc đầu anh cũng cân nhắc, nhưng nó là kiểu 1000 người làm. Anh thì muốn đi vào trọng tâm bài toán cần giải quyết luôn nên không lựa chọn em ah
Khi thiết kế kiến trúc các ông có tính toán trước hành vi người dùng không. Mỗi user request bao lần, các request luồng như nào... hệ thống tăng trưởng user ra sao để scale cho phù hợp
Thiết kế kiến trúc là cả một quá trình anh à. Bất kì một sản phẩm nào đều lấy khách hàng làm trọng tâm. Thì đương nhiên sẽ cần nghiên cứu kĩ hành vi rồi ạ. Còn user request bao nhiêu lần (TPS). Mới đầu sẽ chỉ là con số áng khoảng lấy từ việc load test để làm cơ sở tính toán resource và estimate resource ( đây là bước khởi tạo resource lúc đầu) Sau đó sẽ vận hành, monitor theo dõi tải thực sự và đưa ra chiến lược tiếp. Mọi thứ sẽ đi từ đơn giản đến phức tạp, từ nhỏ đến lớn.
E chưa hiểu đoạn update cache lắm, cái đoạn mà : + active nhưng offline -> online thì vẫn phải query database rồi update lại cache + inactive nhưng offline -> online thì vẫn phải query database rồi update lại cache mà ? => tại sao phải update timeline khi người dùng thường đăng bài trong khi KOL thì không? vì a nói cứ offfline -> online r query mà? thì cần gì update cache khi người dùng thường đăng đâu, vì kiểu gì cũng phải query khi online? thậm chí nó còn tốt cho Cache hơn vì sẽ có ít data trong khi các user đang offline thì không cần update timeline cho họ ?
Theo mình còn một cách phân loại user nữa đó là theo mức độ engage. Hệ thống đánh trọng số đối với các action khác nhau của user như xem, like, comment để tính mức độ engage với một account. Khi account đó đăng bài thì ưu tiên xử lý update timeline cho ông nào chỉ số engage cao trước vì mấy ông đó quan tâm thật sự.
Từ video này e đã thấy được 1 số best practices có thể áp dụng được :D cảm ơn các a
Cảm ơn 2 anh rất nhiều, xem xong học được tư duy thiết kế từ đơn giản đến chi tiết rất hữu ích ạ ❤
Hay quá, cảm ơn Huy và Nam đã chia sẻ thông tin hữu ích này
Kiến thức và góc nhìn tuyệt vời. Không phải lúc nào cũng có cơ hội để có view về hệ thống lớn như này. Cảm ơn anh em đã chia sẻ
Cảm ơn 2 ae vì những chia sẻ rất hay và thực tế. Mong Huy ra thêm nhiều chia sẻ như vậy đóng góp cho cộng đồng
video rất giá trị, hy vọng sẽ ra nhiều video như này trong tương lai. Cảm ơn cộng đồng wecommit
Cảm ơn hai anh, anh Huy và anh Nam. Video chứa nhiều nội dung mình đang cần nên đã xem hết.
Cảm ơn bạn Nguyễn Trung Nam và anh Huy đã host buổi chia sẻ rất hay và bổ ích
Video rất hay, hiểu được cách optimize từng phần của hệ thống lớn
Cám ơn anh Huy và Nam. Quá chất lượng!!!
Chất lượng quá anh ơi. Mong rằng anh ra nhiều video hay như thế này nữa ạ.
Video rất hay, Xem video vỡ ra được nhiều về thiết kế hệ thống
bài rất hay, hiểu được chiến lược thiết kế hệ thống, từ đơn giản, gặp vấn đề thì tách tiếp. Ý tưởng tuyệt vời ạ =))
Video rất hay, hàm chứa nhiều kiến thức, hi vọng sẽ được xem nhiều video từ anh Nam và Huy hơn nữa
Cám ơn Wecommit, Hi vọng Wecommit tiếp tục ra các video về chủ đề System Design.
Trung Nam đúng cây đa cây đề tay nghề siêu cứng. Cảm ơn anh Trần Quốc Huy và anh Trung Nam vì những chia sẻ vô cùng giá trị và cực thú vị.
Cảm ơn anh Huy và anh Nam, nội dung chất lượng quá ạ
Video rất hay, giải quyết vấn đề phức tạp bằng cách bóc tách thành từng vấn đề nhỏ và giải quyết nó
Sếp Trung Nam chia sẻ rất hay và dễ hiểu.
Cảm ơn Idol Duy Database.
Uây, đoạn tư tưởng xây từ đầu hay quá, em cảm ơn 2 anh ạ ❤🔥
Rất hữu ích, cảm ơn anh Huy rất nhiều!
Video rất hay, cảm ơn 2 a!
Rất hay, cảm ơn 2 anh em đã chia sẻ, em sẽ nghiên cứu dần ạ
Nội dung quá chất lượng cảm ơn anh Nam và anh Huy
Bài chia sẻ hay , Cảm ơn anh Huy, anh Nam rất nhiều ạ
Cảm ơn anh Nam, giờ thì dễ hiểu hơn về các xử lý những case khác biệt rồi ạ
Từ thiết kế, Anh Huy làm chi tiết thêm cách tạo ra mấy cái cục, cách kết nối mấy cục đó bằng code đi anh ❤❤🎉🎉🎉🎉
Tkss anh, các videos rất tuyệt vời 🎉🎉🎉🎉🎉🎉
Em cảm ơn anh Huy và anh Nam, chủ đề rất hay và cách tiếp cận đi từ gốc rễ vấn đề. Khi gặp vấn đề mình biết cách xử lý từ đâu
Cảm ơn a 2 anh, nội dung chất lượng quá ạ
Ủng hộ Nam, thợ xây VPS. Mong tìm được nhiều cơ hội để khai thác hơn
Video hay quá! Rất hấp dẫn và hữu ích.
Tuyệt vời, hy vọng có thêm buổi sharing về core Chứng Khoán từ 2 ae :D
Video hay quá, cảm ơn 2 anh em.
Tư duy thiết kế rất hay, cảm ơn 2 anh chia sẻ
Thật sự em đúng cái em đang cần để tối ưu luồng trong dự án của em, cảm ơn anh Huy và anh Nam ạ
Thanks!
Bài rất hay và hữu ích ạ, em cảm ơn 2 anh rất nhiều
Chủ đề rất hay ạ, cảm ơn 2 a đã chia sẻ
Cảm ơn những chia sẻ tuyệt vời ạ.
Cảm ơn anh Huy. Hi vong anh tiếp tục ra các video về chủ đề System Design.
video rất bổ ích, cho mình có nhiều góc nhìn về cách giải quyết vấn đề
Cảm ơn 2 anh ạ, bản thân e là lập trình viên FE, học thêm BE đã nhìn được tổng quan cách thiết kế 1 hệ thống
Cảm ơn các anh đã chia sẻ nhé ạ
Video bổ ích quá. Cảm ơn 2 anh
Rất hữu ích. Cảm ơn 2 a nhiều
Cám ơn các anh đã chia sẻ kiến thức ạ
Cảm ơn 2 ae, video hay quá❤
Đúng là một nghệ thuật.Cảm ơn các anh rất nhiều!!
Video thực sự rất chất lượng, em cám ơn hai anh nhiều, chúc hai anh nhiều sức khỏe và ra nhiều video hay.
Qúa hay. cảm ơn 2 ae
Hay quá anh ơi! Đúng cái em đang tìm hiểu
Video hay quá bạn ơi.
video rat hay, cam on wecommit
Tuyệt vời quá anh Nam ơi
Em rất thích xem video thiết kế hệ thống kiểu này, nhưng mà không biết từ thiết kế ra code thực tế như thế nào, mong anh Huy làm chi tiết thêm.. ❤❤
Tks anh 🎉🎉🎉
chủ đề rất hữu ích, mong anh ra nhiều video hơn ạ
nhiều kiến thức bổ ích. cám ơn 2 anh em đã chia sẻ!
Quá hay luôn anh! Qua video của anh cùng với buổi live về "Chiến lược Scale Database" em mới thấy sai lầm của bản thân đã gặp phải khi thiết kế một hệ thống (dù nhỏ) là cố gắng đưa ra một mô hình phức tạp ngay từ đầu thay vì làm nó đơn giản đáp ứng đủ nhu cầu, đồng thời có thể mở rộng về sau khi đã có đủ lượng người dùng và quan trọng là có doanh thu, lợi nhuận.
Bài chia sẻ rất hữu ích ạ
Hay quá anh ơi, có những buổi chia sẻ như này rất ý nghĩa❤
Quá hay luôn ạ. Em xem từ đầu tới đuôi luôn. Cuốn thiệt sự luôn ạ🎉🎉❤
quá hay anh ơi, thanks
Rất thích nhưng bài phân tích actual cases như này. Cám ơn a Huy!
Tiếc quá chưa có vụ chứng khoán
Các bước trong tưduy tối ưu hay quá anh ạ
Bài rất hay, cảm ơn 2 anh nhiều
càng làm nhiều big data, xong càng tìm hiểu càng thấy nó hay.
Video hay quá bạn ơii ❤❤
Quá hữu ích, hóng video tiếp theo
Mình có xem 1 vid seminar của 1 anh engineer chia sẻ về thiết kế của twitter, thì gần như họ chỉ tương tác với cache, còn database chỉ để lưu trữ thôi. Còn về việc giảm tải bằng cách chia theo status của user thế thì cũng có khả năng, nhưng mà họ sẽ read các bài viết mới nhất của celeb họ follow từ cache luôn, nghĩa là mỗi khi celeb post bài họ sẽ save vào db để lưu trữ + sync qua cache của họ để phục vụ các request.
Hầu như 100% ông lớn MXH nào cũng ưu tiên dùng cache. cache hit đạt 95-96% là bình thường. MXH nào cũng quan trọng thu hút user cho nên phân loại theo tương tác là quan trọng nhất. Còn việc video này giải quyết nó chỉ là 1 phần nhỏ. Nếu giải quyết bài toán phân loại theo user tương tác nhiều khi họ bỏ qua luôn case của video đang giải quyết
cảm ơn anh em rất nhiều.
Rất hay, thanks!
Nội dung rất hữu ích❤
Nội dung quá chất ❤❤
Hay quá Nam ơi ❤
Giọng ông này cảm giác hơi bố đời nhưng kiến thức hay. Cám ơn anh
Cám ơn 2 bạn! chủ đề rất hay, mà chưa tìm được ở đâu ra.
rất hay..tks a
Hay quá ạ 😉
Rất hữu ích ạ
bài hay a ơi
hay ạ. noted!
Bài chia sẻ của bạn rất hay và bổ ích, chỉ một góp ý nhỏ là bạn nói chuyện đừng cương quá, người nghe sẽ cảm thấy rất mệt. Chúc bạn sức khoẻ và ra nhiều video bổ ích nữa nhé 😁
Video rất hữu ích
cám ơn 2 anh
Rất mong được cơ hội gặp các anh ngoài đời
hữu ích quá
Đỉnh quá
chủ đề hữu ích
em thấy đi từ functional/non-functional -> high level design sẽ dể hiểu hơn ạ.
uh, cách tiếp cận này lúc đầu anh cũng cân nhắc, nhưng nó là kiểu 1000 người làm. Anh thì muốn đi vào trọng tâm bài toán cần giải quyết luôn nên không lựa chọn em ah
B thử các bước trên xem nhé. Thì mới cảm nhận được và dễ so sánh
Thanks hai anhh
đỉnh quá 2 anh ơi
very good
Khi thiết kế kiến trúc các ông có tính toán trước hành vi người dùng không. Mỗi user request bao lần, các request luồng như nào... hệ thống tăng trưởng user ra sao để scale cho phù hợp
Thiết kế kiến trúc là cả một quá trình anh à. Bất kì một sản phẩm nào đều lấy khách hàng làm trọng tâm. Thì đương nhiên sẽ cần nghiên cứu kĩ hành vi rồi ạ.
Còn user request bao nhiêu lần (TPS). Mới đầu sẽ chỉ là con số áng khoảng lấy từ việc load test để làm cơ sở tính toán resource và estimate resource ( đây là bước khởi tạo resource lúc đầu)
Sau đó sẽ vận hành, monitor theo dõi tải thực sự và đưa ra chiến lược tiếp.
Mọi thứ sẽ đi từ đơn giản đến phức tạp, từ nhỏ đến lớn.
video hay
E chưa hiểu đoạn update cache lắm, cái đoạn mà :
+ active nhưng offline -> online thì vẫn phải query database rồi update lại cache
+ inactive nhưng offline -> online thì vẫn phải query database rồi update lại cache mà ?
=> tại sao phải update timeline khi người dùng thường đăng bài trong khi KOL thì không?
vì a nói cứ offfline -> online r query mà? thì cần gì update cache khi người dùng thường đăng đâu, vì kiểu gì cũng phải query khi online? thậm chí nó còn tốt cho Cache hơn vì sẽ có ít data trong khi các user đang offline thì không cần update timeline cho họ ?
Bro xem lại lượt nữa nhé :)))
Good❤
Mong chờ Huy system design cho chứng khoán. Có live tương tác không Huy ơi?
có live, anh em vào nhóm telegram là được nhé, trong bình luận có link đó
Nghiệp vụ => kiến trúc => tech stack
Đoạn 22:00 em chưa hiểu lắm ạ, có bác nào giải thích lại giúp em làm sao nó bị duplicate không ạ. em cảm ơn ạ