thắc mắc Nhờ tư vấn thiết kế hệ thống

Em đang build hệ thống mà bên thứ 3 gọi vào API thực hiện 1 hàm X thì phải cần sự xác nhận của người dùng của hệ thống đã đăng kí từ trước thông qua mobile app. Sự xác nhận này có thể sẽ phải mất đến 1-2p. Đến đây em đang phân vân giữa 2 phương án sau:

• PA1: Cho treo request của bên thứ 3 tới khi có xự xác nhận của người dùng.
• PA2: Trả về response cho bên thứ 3 sau khi thông báo tới người dùng, xây dựng thêm hàm API để cho bên thứ 3 truy vấn khi nào người dùng xác nhận xong.

Hệ thống này tương đối lớn, có thể đạt 1M user. Theo các bác em nên chọn phương án nào để tối ưu. Tiện thể em hỏi luôn dựng cloud messaging theo thằng nào là ok ạ, private thì càng tốt.

Joker2288 said:

Em đang build hệ thống mà bên thứ 3 gọi vào API thực hiện 1 hàm X thì phải cần sự xác nhận của người dùng của hệ thống đã đăng kí từ trước thông qua mobile app. Sự xác nhận này có thể sẽ phải mất đến 1-2p. Đến đây em đang phân vân giữa 2 phương án sau:

• PA1: Cho treo request của bên thứ 3 tới khi có xự xác nhận của người dùng.
• PA2: Trả về response cho bên thứ 3 sau khi thông báo tới người dùng, xây dựng thêm hàm API để cho bên thứ 3 truy vấn khi nào người dùng xác nhận xong.

Hệ thống này tương đối lớn, có thể đạt 1M user. Theo các bác em nên chọn phương án nào để tối ưu. Tiện thể em hỏi luôn dựng cloud messaging theo thằng nào là ok ạ, private thì càng tốt.

Click to expand...

PA1 thì ko chơi đc rồi.
PA2 thì có thể nhưng

• Cứ mỗi lân gọi api là cần chờ 1 - 2p xác nhận từ người khác hay sao? VD cần gọi 15 lần thì tổng chờ có thể lên đến 30p.
• Cần biết thêm yêu cầu để rõ

Sao ko làm kiểu người dùng cấp 1 cái dạng như service key có quy định key này đc phép gọi vô hệ thống hay ko? Limit rate,..., đc quyền gọi vô api nào, phần quyền cáckiểu. Expired của key này nếu có...

Chứ mỗi lần gọi là chờ 1 - 2 p để chờ quyền thì

Vấn đề yếu tố xác thực nằm ở phía người dùng, hệ thống không cấp quyền được cho bên thứ 3 được, và quá trình xác thực này nó cũng khá lằng nhằng một phần hệ thống này là về security nên muốn ngắn hơn cũng khó.

Joker2288 said:

Vấn đề yếu tố xác thực nằm ở phía người dùng, hệ thống không cấp quyền được cho bên thứ 3 được, và quá trình xác thực này nó cũng khá lằng nhằng một phần hệ thống này là về security nên muốn ngắn hơn cũng khó.

Click to expand...

Ý là mình là sao ko dựng hệ thống cho phép người có thẩm quyền chứng thực và cấp phát access key cho bên thứ 3 á ? Cái người mà đi xác thực mất 1 - 2 phút á.

Mà tới đây mình vẫn chưa rõ là việc xác thực cấp quyền luôn luôn và bắt buộc thưc hiện khi có request vô api hả? ??

Dữ liệu của người dùng được lưu trong một phần cứng riêng biệt, bên thứ 3 muốn sử dụng dữ liệu này thì phải được người dùng cấp quyền bằng cách giao tiếp với thiết bị thông qua API, giao thức xác thực này là do thiết bị phần cứng kia quy định. Còn kiểu access key bạn nói thì do server software quy định nên nó không phải vấn đề.

bài toán của chủ thớt cũng đơn giản thôi, cái này thực tế thấy nhiều mà vd như phần xác thực MFA dùng app ấy
đơn giản nhất thì chủ thớt tham khảo mấy cái Async API của mấy framework serverless rồi làm tương tự thôi (vd openwhisk), cơ bản sẽ cần có message queue, request tới trả về request id, cơ chế push về client khi xử lý xong request (còn đơn giản hơn thì client sau 1 khoảng thời giản kiểm tra trạng thái request -> nhưng không tối ưu)

Joker2288 said:

Dữ liệu của người dùng được lưu trong một phần cứng riêng biệt, bên thứ 3 muốn sử dụng dữ liệu này thì phải được người dùng cấp quyền bằng cách giao tiếp với thiết bị thông qua API, giao thức xác thực này là do thiết bị phần cứng kia quy định. Còn kiểu access key bạn nói thì do server software quy định nên nó không phải vấn đề.

Click to expand...

Theo mình hiểu thì như nhau

Như hiện tại user cấp quền cho access api như thế nào?

Theo như bạn nói thì gọi lần nào thì chờ cấp quyền xong mới đc làm. Và việc này lăp lại dù lần gọi trc đã đc cấp quyền

Mà nói chung cái mình nói đến là để tránh vụ cấp quyền lặp đi lặp lại kia trong khi nó lâu v~ cả nồi

Thêm nữa, giả sử việc trên ko thể tránh đc vì đó là bắt buộc thế thì cứ táng theo pa2 của bạn

via nextVOZ for iPhone

Joker2288 said:

Em đang build hệ thống mà bên thứ 3 gọi vào API thực hiện 1 hàm X thì phải cần sự xác nhận của người dùng của hệ thống đã đăng kí từ trước thông qua mobile app. Sự xác nhận này có thể sẽ phải mất đến 1-2p. Đến đây em đang phân vân giữa 2 phương án sau:

• PA1: Cho treo request của bên thứ 3 tới khi có xự xác nhận của người dùng.
• PA2: Trả về response cho bên thứ 3 sau khi thông báo tới người dùng, xây dựng thêm hàm API để cho bên thứ 3 truy vấn khi nào người dùng xác nhận xong.

Hệ thống này tương đối lớn, có thể đạt 1M user. Theo các bác em nên chọn phương án nào để tối ưu. Tiện thể em hỏi luôn dựng cloud messaging theo thằng nào là ok ạ, private thì càng tốt.

Click to expand...

zulu said:

PA1 thì ko chơi đc rồi.
PA2 thì có thể nhưng

• Cứ mỗi lân gọi api là cần chờ 1 - 2p xác nhận từ người khác hay sao? VD cần gọi 15 lần thì tổng chờ có thể lên đến 30p.
• Cần biết thêm yêu cầu để rõ

Sao ko làm kiểu người dùng cấp 1 cái dạng như service key có quy định key này đc phép gọi vô hệ thống hay ko? Limit rate,..., đc quyền gọi vô api nào, phần quyền cáckiểu. Expired của key này nếu có...

Chứ mỗi lần gọi là chờ 1 - 2 p để chờ quyền thì

Click to expand...

Tại sao cách 1 không được? Theo mình là PA1 nhá bác. Cái này mấy bác xài hàng ngày mà cũng hỏi à

Yêu cầu thấy hơi khó hiểu, mình đang hiểu là user sẽ “sign in” bằng một thiết bị phần cứng?

RPG29 said:

Yêu cầu thấy hơi khó hiểu, mình đang hiểu là user sẽ “sign in” bằng một thiết bị phần cứng?

Click to expand...

Sign in hay làm gì không cần biết. Cái này là yêu cầu người dùng cấp quyền. Ví dụ như 3rd system đòi thanh toán qua tài khoản ngân hàng thì nó gọi service của ngân hàng nhưng vẫn phải chờ OTP của người dùng approve. Nó set time out 1 khoảng rồi chờ, ko thì cancel cái transaction đó thôi.

zulu said:

Theo mình hiểu thì như nhau

Như hiện tại user cấp quền cho access api như thế nào?

Theo như bạn nói thì gọi lần nào thì chờ cấp quyền xong mới đc làm. Và việc này lăp lại dù lần gọi trc đã đc cấp quyền

Mà nói chung cái mình nói đến là để tránh vụ cấp quyền lặp đi lặp lại kia trong khi nó lâu v~ cả nồi

Thêm nữa, giả sử việc trên ko thể tránh đc vì đó là bắt buộc thế thì cứ táng theo pa2 của bạn

via nextVOZ

Click to expand...

zulu said:

Theo mình hiểu thì như nhau

Như hiện tại user cấp quền cho access api như thế nào?

Theo như bạn nói thì gọi lần nào thì chờ cấp quyền xong mới đc làm. Và việc này lăp lại dù lần gọi trc đã đc cấp quyền

Mà nói chung cái mình nói đến là để tránh vụ cấp quyền lặp đi lặp lại kia trong khi nó lâu v~ cả nồi

Thêm nữa, giả sử việc trên ko thể tránh đc vì đó là bắt buộc thế thì cứ táng theo pa2 của bạn

via nextVOZ for iPhone

Click to expand...

Bạn có thể hiểu như #10, nó tương tự như vậy

chautieu47 said:

Tại sao cách 1 không được? Theo mình là PA1 nhá bác. Cái này mấy bác xài hàng ngày mà cũng hỏi à

Click to expand...

Bác muốn hold request tới cỡ nào? Chưa thấy hệ thống nào làm ăn chụp giật vậy.

Joker2288 said:

Bạn có thể hiểu như #10, nó tương tự như vậy

Click to expand...

OK vậy là bắt buộc ,
Vậy bác cứ theo PA2 thôi

dùng cơ chế pub/sub -> thằng 3rd sub vào hệ thống (làm màn hình count down chẳng hạn) -> người dùng xác nhận 1 tiếng cũng được, sau khi xác nhận xong thì pub lại cho thằng sub -> done.
Keywords:

• Client cho FE: HTML SSE (Server-Sent Events)...
• Backend: nginx nchan, redis (pub/sub), websocket...

via theNEXTvoz for iPhone

zulu said:

Bác muốn hold request tới cỡ nào? Chưa thấy hệ thống nào làm ăn chụp giật vậy.

Click to expand...

Bác xài internet banking nó hold cho bác vài phút để nhập OTP đó thôi.

via theNEXTvoz for iPhone

chautieu47 said:

Bác xài internet banking nó hold cho bác vài phút để nhập OTP đó thôi.

via theNEXTvoz for iPhone

Click to expand...

v~ cái đó đâu phải treo hay hold request của client cho tới khi có response mới đc trả về cho client ông thần.
VD của ông thì trong lúc chờ OTP đâu có 1 request nào bị block chờ responnse đâu. Đơn gian là khi nào user nhập otp xong nhấn submit thì mới gửi request lên mà.

zulu said:

v~ cái đó đâu phải treo hay hold request của client cho tới khi có response mới đc trả về cho client ông thần.
VD của ông thì trong lúc chờ OTP đâu có 1 request nào bị block chờ responnse đâu. Đơn gian là khi nào user nhập otp xong nhấn submit thì mới gửi request lên mà.

Click to expand...

Request ở đây tôi hiểu là business request chứ ko phải 1 cái HTTP Request của 1 công nghệ cụ thể. Code thế nào thì tôi ko bàn (#14 cũng là 1 cách). Còn về mặt thiết kế, cái PA2 là "tiền trảm hậu tấu" bác đưa thông tin người dùng trước khi được approve là sai. Theo tôi phải đi theo cách 1 là hold cho tới khi người dùng approve rồi mới xử lý tiếp.

Cái này trên smartphone có đầy chứ đâu. Một cái app khi cần access Camera, Photos, Bluetooth nó cũng phải hỏi user cho phép nó mới làm đó thôi.

chautieu47 said:

Request ở đây tôi hiểu là business request chứ ko phải 1 cái HTTP Request của 1 công nghệ cụ thể. Code thế nào thì tôi ko bàn (#14 cũng là 1 cách). Còn về mặt thiết kế, cái PA2 là "tiền trảm hậu tấu" bác đưa thông tin người dùng trước khi được approve là sai. Theo tôi phải đi theo cách 1 là hold cho tới khi người dùng approve rồi mới xử lý tiếp.

Click to expand...

Đưa hồi nào bác? PA2 chưa hề trảm lấy j hậu tấu?

Còn theo PA1 thớt nói, thì bác đòi hỏi hệ thông giữ request trong khi chờ IO ( chờ user xác thực ) là lãng phí vô ích. Khi thời gian chờ lên tới 1 -> 2 phút. Lên tới 1000, 10000, 100000 ... request cùng lúc chờ 1 -> 2 phút thì backend ăn cám vs nhau à?
Cách của #14 chỉ là 1 cách implement cụ thể của PA2 mà thôi.
Tôi nói r , chưa có 1 hệ thống nào làm như PA1 mà thớt nói đâu. Cái VD OTP ngân hàng thì nó thực chất là mô hình na ná PA2.

chautieu47 said:

Cái này trên smartphone có đầy chứ đâu. Một cái app khi cần access Camera, Photos, Bluetooth nó cũng phải hỏi user cho phép nó mới làm đó thôi.

Click to expand...

Vl, bác đánh đồng 2 trường hơp? Trg hợp request access camera, photo xảy ra cục bộ trên client app của 1 người dùng KO HỀ GIỐNG VÀ LIÊN QUAN j đến vấn đề của thớt, đánh đồng 2 cái là ko đc.

chautieu47 said:

Còn về mặt thiết kế, cái PA2 là "tiền trảm hậu tấu" bác đưa thông tin người dùng trước khi được approve là sai.

Click to expand...

PA2 Chưa bao giờ nói lên điều này nhé. Không hề có chuyện cho truy cập vô data trước khi đc approve cả.
Thề bác còn chưa hiểu PA2 luôn.

• Lần đầu gọi vô api lần đầu nó ghi nhân là đã nhận yêu cầu và trả về liền đang xử lý. Lúc này có gọi vô api thì vẫn ko access data đc ( vì chưa đc approved) --> tạm gọi là requestAccess
• Như VẬY mới cần 1 đầu api để check status --> gọi là checkAccessStatus. Khi nào xong thì làm bước bên dưới
• Gọi vô api truy cập database

zulu said:

Đưa hồi nào bác? PA2 chưa hề trảm lấy j hậu tấu?

Còn theo PA1 thớt nói, thì bác đòi hỏi hệ thông giữ request trong khi chờ IO ( chờ user xác thực ) là lãng phí vô ích. Khi thời gian chờ lên tới 1 -> 2 phút. Lên tới 1000, 10000, 100000 ... request cùng lúc chờ 1 -> 2 phút thì backend ăn cám vs nhau à?
Cách của #14 chỉ là 1 cách implement cụ thể của PA2 mà thôi.
Tôi nói r , chưa có 1 hệ thống nào làm như PA1 mà thớt nói đâu. Cái VD OTP ngân hàng thì nó thực chất là mô hình na ná PA2.


PA2 Chưa bao giờ nói lên điều này nhé. Không hề có chuyện cho truy cập vô data trước khi đc approve cả.
Thề bác còn chưa hiểu PA2 luôn.

• Lần đầu gọi vô api lần đầu nó ghi nhân là đã nhận yêu cầu và trả về liền đang xử lý. Lúc này có gọi vô api thì vẫn ko access data đc ( vì chưa đc approved) --> tạm gọi là requestAccess
• Như VẬY mới cần 1 đầu api để check status --> gọi là checkAccessStatus. Khi nào xong thì làm bước bên dưới
• Gọi vô api truy cập database

Click to expand...

Tôi đã nói request ở đây là business request, implement thì có nhiều cách tất nhiên không ai làm treo http request trên server rồi.

Còn PA2:

PA2: Trả về response cho bên thứ 3 sau khi thông báo tới người dùng, xây dựng thêm hàm API để cho bên thứ 3 truy vấn khi nào người dùng xác nhận xong.

Click to expand...

Response ở đây có chứa thông tin cần lấy ko? Nếu ko thì OK. Mà như vậy thì có gì để bàn đâu request access -> pending -> aproved -> proceed.. cái này là chuyển trạng thái thôi đâu quan tâm thời gian 1, 2 phút hay thậm chí vài ngày.

chautieu47 said:

Tôi đã nói request ở đây là business request, implement thì có nhiều cách tất nhiên không ai làm treo http request trên server rồi.

Click to expand...

Thế là ngay từ đầu bác là người hiểu sai PA1 mà thớt nói nhé.
Thớt đã nói là treo request ở trên sever rồi.

chautieu47 said:

Còn PA2:
Response ở đây có chứa thông tin cần lấy ko? Nếu ko thì OK. Mà như vậy thì có gì để bàn đâu request access -> pending -> aproved -> proceed.. cái này là chuyển trạng thái thôi đâu quan tâm thời gian 1, 2 phút hay thậm chí vài ngày.

Click to expand...

Tất nhiên ko rồi. bác có đọc hết ko vậy trời?

Joker2288 said:

• PA2: Trả về response cho bên thứ 3 sau khi thông báo tới người dùng, xây dựng thêm hàm API để cho bên thứ 3 truy vấn khi nào người dùng xác nhận xong.

Click to expand...

Bác ko thấy thớt và tôi đều nói sau khi đc cấp quyền thì mới truy cập đc vô database à?
Đọc thì đọc cho hết chứ, đọc nửa rồi nói sai sao đc.
Vì PA2 thiết kế như vậy nên mới ko sợ vụ thời gian chờ bao lâu.