Mình mới sử dụng ruby, mình từ js và php qua nên vẫn thích làm theo kiểu cũ: tạo 1 hàm xác thực, trả về bool, mình thấy sử dụng cũng ngắn gọn, không cần cài thêm gói, bên dưới là code của mình

  def validate_captcha
    uri = URI('https://www.google.com/recaptcha/api/siteverify')
    request_params = {
      :response => params['g-recaptcha-response'],
      :secret   => captcha_private_key
    }
    uri.query = URI.encode_www_form(request_params)
    res = Net::HTTP.get_response(uri)

    result = false
    if res.is_a?(Net::HTTPSuccess)
      body = JSON.parse res.body
      if body['success'].present? && body['success'] == true
        result = true
      end
    end
    result
  end

Mình đang chạy 1 server elastic như 1 node vậy nếu mình mở rộng như cách của bạn thì cái server thứ 2 cũng phải cung cấu hình với cái đầu phải không bạn.

Họ làm bên bất động sản, không biết code mà cũng không thuê Dev, coi hướng dẫn làm Wordpress thì làm sao mà tự debug được.

yep, vậy mình mới nói phụ thuộc vào team skill khá nhiều nhưng trước mắt cứ phải hiểu đúng và đủ cái đã rồi tính tiếp

Chào b. tôi có thể liên hệ với bạn ntn. Vì có một số lỗi nằm ở code

nai xừ

có nhiều lib + framework để làm saga đó em: temporal.io, eventuate.io... nhưng flow a nghĩ chỉ vài service thôi chứ, flow mà span ra cả mấy chúc service a cũng chưa thấy bao giờ ngoài ra saga chỉ là 1 phải giáp, k phải lúc nào apply saga cũng hay

đọc bài sau của a để biết cách sắp xếp transaction hợp lí nhé -> paymentService nên là pivot transaction. tất cả các event e đều cần có correlation id nhé. ví dụ với bài này correlation_id là order_id. Khi lưu data e phải lưu cả id này cùng record -> khi nhận event e có c_id đó r, bản thân thông tin rollback đã store trong record đó r, vấn đề là làm cách nào tìm đúng record -> c_id.

hiện tại có 3 cách để làm em nhé:

1. polliing publíher: chính là relay publisher ở trên, nó hiệu quả với bài toán k cần real-time, và lượng event ít.
2. transaction log tailing: e có thể tham khảo debezium nhé, idea là nó read file transaction log để build event
3. publish id: e publish trước event id sang 1 service khác, service khác đó sẽ read data từ db với id đó để publish. phải impl thêm retry hoặc cancel eventid...

theo mình khởi đầu thì có thể tham khảo Factory Method hoặc Builder Method, 2 cái này đều dùng cho khởi tạo khá dễ áp dụng trong các dự án, ko rõ cụ thể bạn đang làm với công nghệ nào nhỉ

Okie em. Em có thể xem thêm các bài viết của anh ở đây nhé.

https://hblab-ngocnd.github.io/blogs/

Hay quá a. Nhưng mà e thấy quả SAGA pattern này hâu như phải implement bằng cơm và cũng vất vả để apply nó một cách ngon nghẻ . Như chỗ e hiện tại nó đang nở ra tận mấy chục con microservice mà tất cả service đấy muốn apply saga thì đúng vỡ mồm thật.

À e có thêm 1 thắc mắc nữa ạ. Ví dụ e sử dụng Orchestration -> sau khi e thanh toán xong, cộng trừ tiền các kiểu cho khách rồi, lưu vào DB luôn rồi, khách hàng đã thấy trên máy mình đã bị trừ tiền rồi.(tức là transaction ở paymentService đã được commit, và đóng rồi) -> sau đến nhà bếp service thì hết nguyên liệu thì nhà bếp bắn ra lỗi cho orchestration -> sau đấy orchestration trigger cho paymentService là không có nguyên liệu làm , mày trả lại tiền cho người ta đi -> thì chỗ này thằng paymentService phải lấy thông tin đâu ra để rollback lại ạ. (vì e nghĩ là paymenService và nhà bếp service sẽ là 2 localTransaction khác nhau). Liệu lúc save hay update dữ liệu có nên tạo ra 1 bản backup hay không -> nếu tạo thì sẽ có phải là bảng nào nằm trong vùng quản lý orchestration cũng phải tạo 1 bảng backup hay không. E cảm ơn.

e có câu hỏi như này ạ. Ở chỗ paymentService , sau khi thực hiện bussiness thanh toán tiền xong -> thì lưu thông tin thanh toán vào DB và đồng thời lưu vào out_box table (cả 2 thằng save này đều ngon nghe). Thì ở chỗ này tiếp theo a sẽ publish message lên kafka (xem như là mình đã chọn kafka làm message broker) để thằng relay publisher sẽ consumes. hay là a sẽ tạo schedule tại relay publisher để quét những message đã được lưu ạ. Thanks a vì những bài viết hay như thế này ạ.

Cảm ơn bác đã chia sẻ nhá. Thoạt nhìn bài toán có vẻ đơn giản nhưng làm thì thấy cũng rối rắm lắm. Bữa mình code mà k note rõ các trường hợp ra, sai tè le luôn

đỉnh quá

Series rất hay, cảm ơn bác nhiều.

"Bàn giao muộn và các phần chưa được hoàn thành là những dấu hiệu cho thấy tốc độ quá nhanh hoặc có quá nhiều việc phải thực hiện. Kết thúc sớm có nghĩa là tốc độ đang quá chậm hoặc team có khả năng hơn và không gặp thách thức nào."

Đoạn này nghe mâu thuẫn quá.

Anh cho e xin source chall friends được k ạ?

mình cũng có xem qua 1 số Design Pattern nhưng vẫn chưa hiểu nó apply vào code như nào