Tác giả: Israel Lopez Moriano, Cristóbal Lopez Callejon, and Jesús Bernal
Ngày phát hành: 14 JAN 2026
Chuyên mục: Amazon DynamoDB, Amazon EventBridge, Amazon Simple Queue Service (SQS), AWS Lambda, AWS Management Console, AWS Step Functions, Financial Services, Industries

Giới thiệu về bối cảnh thanh toán hiện đại

Sự phát triển nhanh chóng của thanh toán kỹ thuật số đã thay đổi cơ bản cách các doanh nghiệp xử lý giao dịch tài chính, với các bộ xử lý thanh toán trở thành đối tác thiết yếu trong quá trình chuyển đổi này. Các bộ xử lý thanh toán hiện đại cung cấp cơ sở hạ tầng nền tảng xử lý sự phức tạp của việc xử lý thanh toán, tuân thủ và các phương thức thanh toán toàn cầu. Khi cơ sở hạ tầng này tích hợp với các dịch vụ đám mây của AWS, nó cho phép các tổ chức xây dựng các kiến trúc hướng sự kiện tinh vi, phản ứng thông minh với các sự kiện thanh toán theo thời gian thực, điều phối các quy trình kinh doanh phức tạp và mang lại khả năng mở rộng cũng như độ tin cậy, những yếu tố cần thiết cho các ứng dụng hiện đại.

Sau khi thanh toán thành công, các hệ thống cần thực hiện đơn hàng, cập nhật tài khoản khách hàng, gửi xác nhận và kích hoạt các quy trình phân tích. Nếu thanh toán thất bại, các hệ thống phải khởi tạo quy trình khôi phục, cập nhật mô hình rủi ro và liên lạc với khách hàng. Các phương pháp truyền thống dựa trên webhook gặp khó khăn với sự phức tạp và quy mô của các yêu cầu này, trong khi các kiến trúc hướng sự kiện được cung cấp bởi Amazon EventBridge cung cấp sự linh hoạt và khả năng phục hồi cần thiết cho các hệ thống thanh toán hiện đại.

Bộ xử lý thanh toán và AWS: Cùng nhau tốt hơn

AWS và các bộ xử lý thanh toán hàng đầu đang thúc đẩy đổi mới để thay đổi cách các doanh nghiệp xử lý giao dịch tài chính trong thời đại kỹ thuật số. Sự kết hợp mạnh mẽ này phục vụ các tổ chức thuộc mọi quy mô thông qua ba trụ cột chính:

• Thúc đẩy tăng trưởng và đổi mới thông qua trải nghiệm khách hàng mới và các mô hình kinh doanh sáng tạo.
• Hiện đại hóa và tối ưu hóa hoạt động kinh doanh để thúc đẩy hiệu quả bằng cách hiện đại hóa việc lập hóa đơn và thanh toán cùng với việc hợp lý hóa chi phí kỹ thuật, quy trình làm việc của nhà phát triển và triển khai với kiến trúc không hoặc ít mã.
• Giảm thiểu rủi ro bằng cách tuân thủ các yêu cầu quy định, tự tin mở rộng sang các quốc gia mới và giảm gian lận cũng như các khoản thanh toán tranh chấp.

Bằng cách kết hợp chuyên môn sâu về xử lý thanh toán của các nhà lãnh đạo ngành với khả năng đám mây của AWS, các doanh nghiệp có thể xây dựng các hệ thống thanh toán có khả năng mở rộng, linh hoạt và đổi mới, phù hợp với nhu cầu tài chính hiện đại. Hiện tại, các bộ xử lý thanh toán có tích hợp EventBridge gốc bao gồm Stripe, Checkout.com và PayShield, với các bộ xử lý bổ sung tham gia vào hệ sinh thái này thường xuyên.

Giải quyết các trường hợp sử dụng kinh doanh thông qua kiến trúc hướng sự kiện

Khả năng tích hợp hướng sự kiện của bộ xử lý thanh toán cho phép các tổ chức phản ứng linh hoạt với nhiều hoạt động liên quan đến thanh toán. Khi các giao dịch và tương tác xảy ra trong nền tảng thanh toán của bạn, hệ thống sẽ tạo ra các sự kiện bất biến chứa thông tin chi tiết về các hoạt động này.

Các sự kiện này đóng vai trò là yếu tố kích hoạt mạnh mẽ cho nhiều trường hợp sử dụng quan trọng trong kinh doanh và các quy trình tuân thủ quy định, chẳng hạn như:

• Phản ứng với các khoản thanh toán định kỳ để triển khai các quy trình làm việc tùy chỉnh.
• Triển khai các chương trình khách hàng thân thiết dựa trên giao dịch mua của người dùng cuối.
• Xây dựng kiểm soát hàng tồn kho theo thời gian thực.
• Tạo hóa đơn tùy chỉnh để đáp ứng các yêu cầu quy định.

Hãy cùng khám phá cách làm cho các sự kiện của bộ xử lý thanh toán có sẵn trên AWS thông qua Amazon EventBridge và đi sâu vào cách xây dựng hai trong số các trường hợp sử dụng được nêu ở trên.

Tích hợp bộ xử lý thanh toán với Amazon EventBridge

Amazon EventBridge là một dịch vụ bus sự kiện phi máy chủ giúp đơn giản hóa việc tích hợp ứng dụng. Các nhà sản xuất xuất bản các sự kiện trên một bus và EventBridge định tuyến chúng đến các người tiêu dùng quan tâm dựa trên các quy tắc có thể cấu hình. EventBridge gọi các người tiêu dùng là đích và cung cấp hơn 20 tích hợp sẵn.

Hình 1. Kiến trúc bus EventBridge

EventBridge cung cấp tích hợp gốc với các bộ xử lý thanh toán được hỗ trợ thông qua các bus sự kiện đối tác chuyên dụng, cho phép nhận sự kiện trực tiếp trong tài khoản AWS của bạn. Tích hợp này loại bỏ sự phức tạp của việc triển khai webhook truyền thống, nơi bạn cần xây dựng, xuất bản và duy trì các điểm cuối API.

Để bật tính năng này, bạn cần thực hiện cấu hình một lần với các hành động trong cả bộ xử lý thanh toán và tài khoản AWS của bạn. Các bước cụ thể khác nhau tùy theo bộ xử lý nhưng tuân theo một mẫu chung. Hãy cùng xem cách cấu hình tích hợp này bằng cách sử dụng Stripe làm ví dụ:

1. Mở tab Webhooks trong Workbench.
2. Chọn nút +Add destination. Stripe hỗ trợ hai cấu hình để gửi sự kiện từ: Your account và Connected accounts. Để đơn giản, hãy chọn Your account để lắng nghe các sự kiện từ tài khoản của riêng bạn.
3. Chọn các loại sự kiện bạn muốn đích này nhận. Sau đó, chọn Continue.

Hình 2. Cấu hình đích sự kiện trên Stripe: nguồn và loại sự kiện

4. Chọn Amazon EventBridge làm loại đích của bạn. Chọn Continue và sau đó nhập ID tài khoản AWS và Region của bạn. Tùy chọn, nhập tên và mô tả đích.
5. Chọn Create Destination.

Hình 3. Cấu hình đích sự kiện trên Stripe: đích tài khoản và Region AWS

Các bước trên sẽ tạo một nguồn sự kiện đối tác trong tài khoản và Region AWS được cung cấp. Các bước cấu hình tương tự áp dụng cho các bộ xử lý được hỗ trợ khác như Checkout.com và PayShield, với các biến thể cụ thể của bộ xử lý trong giao diện và thuật ngữ.

Để nhận sự kiện, bạn cần liên kết nguồn sự kiện này với một bus sự kiện. Tiếp tục với ví dụ Stripe, đây là các bước cần thực hiện trên AWS Console của bạn:

1. Trong EventBridge, điều hướng đến Partner event sources từ phần Integration trên menu bên trái.
2. Bạn sẽ thấy nguồn sự kiện đối tác mới được tạo, với Amazon Resource Name (ARN) khớp với aws.partner/stripe.com/{UNIQUE_ID}. Chọn Associate with event bus.

Hình 4. Liên kết nguồn sự kiện đối tác của Stripe với một bus sự kiện

3. Nếu cần, sử dụng phần Permissions để xác định tài khoản AWS nào sẽ có quyền truy cập vào bus sự kiện.
4. Chọn Associate.

Sau khi bạn hoàn tất cấu hình, bus sự kiện của bạn sẽ nhận các sự kiện từ bộ xử lý thanh toán của bạn. Tuy nhiên, bạn chưa xử lý bất kỳ sự kiện nào trong số đó.

Hãy cùng tìm hiểu cách thực hiện điều đó thông qua một vài trường hợp sử dụng thực tế sẽ làm nổi bật thêm các tính năng của EventBridge và cho bạn cái nhìn thoáng qua về những gì có thể đạt được thông qua tích hợp này.

Thanh toán định kỳ

Các công ty Software-as-a-Service thống trị thị trường ngày nay, chuyển đổi mức tiêu thụ từ giấy phép trọn đời sang các gói đăng ký. Theo mô hình này, khách hàng thường trả một khoản phí định kỳ để sử dụng phần mềm, thay thế các mô hình mua một lần cũ hơn. Mỗi khi một khoản thanh toán định kỳ diễn ra – dù thành công hay không – bộ xử lý thanh toán sẽ tạo ra sự kiện tương ứng được sử dụng để xây dựng chức năng. Một kịch bản phổ biến là gửi thông báo cho người dùng cuối để cho họ biết mọi thứ đều ổn và họ có thể tiếp tục sử dụng dịch vụ hoặc, ngược lại, có điều gì đó không thành công và cần sự chú ý của họ.

Hình 5. Quy trình thanh toán định kỳ

Sau đây là ví dụ về email được gửi cho người dùng cuối khi khoản thanh toán hàng tháng không thành công.

Hình 6. Ví dụ về email được gửi cho người dùng cuối khi thanh toán định kỳ không thành công

Mục tiêu của bạn là xây dựng một dịch vụ lắng nghe các sự kiện được tạo ra bởi các khoản thanh toán thành công hoặc không thành công và gửi các thông báo tương ứng cho người dùng cuối. Ngoài ra, hãy xem xét các yêu cầu sau:

• Gửi thông báo trong vòng 1 phút sau khi thử thanh toán.
• Bạn không muốn cung cấp và quản lý cơ sở hạ tầng, mà chỉ tập trung vào logic kinh doanh.
• Gửi thông báo qua hai kênh khác nhau: email và thông báo đẩy.

Biết chức năng cần xây dựng, hãy tập trung vào việc triển khai kỹ thuật. Đây là kiến trúc bạn sẽ xây dựng:

Hình 7. Kiến trúc hệ thống thông báo trạng thái thanh toán

Đây là những lựa chọn phù hợp nhất:

• Amazon Simple Queue Service (SQS). EventBridge có thể gửi sự kiện trực tiếp đến các đích. Trên thực tế, nó hỗ trợ các chính sách thử lại, cho phép bạn thực hiện một số lần thử gửi khi xảy ra lỗi. Tuy nhiên, việc sử dụng hàng đợi SQS ở giữa (biến hàng đợi thành đích thực tế) mang lại một số lợi thế:
  • Tính bền vững: các sự kiện được lưu trữ vượt quá giới hạn chính sách thử lại của EventBridge là 24 giờ.
  • Bộ đệm: trong trường hợp có một lượng lớn sự kiện, chúng sẽ được lưu trữ trong hàng đợi cho phép người tiêu dùng xử lý tin nhắn theo tốc độ của riêng họ mà không làm quá tải các dịch vụ hạ nguồn.
  • Xử lý hàng loạt: các worker hàng đợi có thể truy xuất và xử lý một số tin nhắn cùng một lúc.
• AWS Lambda tích hợp gốc với các hàng đợi SQS. Dịch vụ này đảm nhiệm việc thăm dò tin nhắn và xóa chúng khỏi hàng đợi khi xử lý thành công, giảm lượng mã mà các nhà phát triển cần viết và duy trì. Tuy nhiên, Lambda là một dịch vụ phi máy chủ không có cơ sở hạ tầng để quản lý và một mô hình trả tiền theo mức sử dụng hiệu quả về chi phí.

Bây giờ, hãy xem cách tạo và cấu hình các thành phần này bằng cách sử dụng AWS Management Console.

Amazon SQS

Điều hướng đến Amazon SQS sẽ đưa bạn đến trang Queues, sau đó:

1. Chọn Create queue.
2. Nhập tên hàng đợi và đảm bảo loại hàng đợi là Standard.
3. Để các cài đặt còn lại ở giá trị mặc định. Tìm hiểu thêm về chúng tại đây.
4. Chọn Create queue.

Hình 8. Tạo hàng đợi để lưu trữ các sự kiện lập hóa đơn

Amazon EventBridge

Để triển khai này, bạn cần xử lý các loại sự kiện cụ thể từ bộ xử lý thanh toán liên quan đến thanh toán hóa đơn. Sử dụng Stripe làm ví dụ, đây sẽ là invoice.paid và invoice.payment_failed. Các loại sự kiện có thể khác nhau giữa các bộ xử lý, vì vậy hãy tham khảo tài liệu của bộ xử lý của bạn để biết tên sự kiện thích hợp.

Như đã nêu trước đây, một bus EventBridge định tuyến các sự kiện đến các người tiêu dùng quan tâm khi chúng đáp ứng các tiêu chí nhất định. Bạn xác định các điều kiện này bằng cách sử dụng các mẫu sự kiện trong các quy tắc. Trong trường hợp này, bạn muốn có một người tiêu dùng chỉ gửi thông báo cho các sự kiện trạng thái thanh toán đến thông qua bus sự kiện đối tác của Stripe. Để tạo quy tắc như vậy, hãy làm theo các bước sau:

1. Truy cập EventBridge và trong Buses chọn Rules.
2. Trong menu thả xuống Event bus, tìm bus đối tác bộ xử lý thanh toán của bạn và chọn Create rule.
3. Cung cấp tên và mô tả có ý nghĩa. Đảm bảo nó được bật và chọn Next.
4. Trong bước Build event pattern, chọn Other làm nguồn sự kiện. Đối với phần mẫu sự kiện, đảm bảo Creation Method là Customer pattern (JSON editor) và nhập một mẫu sự kiện khớp với cấu trúc sự kiện của bộ xử lý của bạn.

{
  "source": [{
    "prefix": "aws.partner/{your-payment-processor}"
  }],
  "detail-type": [
    "invoice.paid",
    "invoice.payment_failed"
  ]
}

Các mẫu sự kiện là một cơ chế lọc mạnh mẽ, kiểm soát việc định tuyến sự kiện bằng cách cho phép bạn xác định các điều kiện cụ thể mà các sự kiện phải khớp. Khi một sự kiện thỏa mãn các tiêu chí mẫu đã xác định, nó sẽ tự động được gửi đến các đích được chỉ định để xử lý. Để tìm hiểu thêm về các mẫu sự kiện, vui lòng đọc trang tài liệu Amazon EventBridge event patterns.

Hình 9. Bước xây dựng mẫu sự kiện trong quá trình tạo quy tắc

5. Bây giờ hãy chọn các đích cho quy tắc. Chọn AWS service và sau đó SQS queue từ menu thả xuống. Chọn hàng đợi bạn đã tạo trước đó, và trong Execution role, để Create a new for this specified resource được chọn. EventBridge đảm nhận một IAM role khi gửi sự kiện đến các đích. Với cài đặt này, bạn đang tạo một role mới với các quyền cho phép EventBridge gửi tin nhắn đến hàng đợi SQS.
6. Trong Additional settings, bạn có thể chuyển đổi sự kiện sẽ được chuyển đến đích, cấu hình chính sách thử lại và thậm chí là hàng đợi Dead-letter (hữu ích cho những sự kiện không thể gửi đến đích sau khi chính sách thử lại đã hết). Để giá trị mặc định. Chọn Next.
7. Thêm thẻ vào quy tắc theo chính sách của tổ chức bạn và chọn Next.
8. Xem lại tất cả các chi tiết của quy tắc và chọn Create Rule.

AWS Lambda

Bước cuối cùng là triển khai một hàm Lambda xử lý các sự kiện từ hàng đợi SQS và xử lý việc gửi thông báo.

Tạo một hàm Lambda là một quy trình được ghi lại rõ ràng. Để bắt đầu, hãy làm theo các bước từ trang tài liệu Create your first Lambda function. Hãy đi sâu vào tích hợp với SQS và các cài đặt có sẵn.

Giả sử bạn đã tạo hàm Lambda. Từ tổng quan về hàm, chọn Add trigger và chọn hàng đợi SQS bạn đã tạo trong các bước trước.

Hình 10. Cấu hình hàng đợi SQS làm kích hoạt cho hàm Lambda

Lambda hỗ trợ các phương thức gọi khác nhau. Đối với các lời gọi dựa trên luồng và hàng đợi, Lambda sử dụng một ánh xạ nguồn sự kiện, một trình thăm dò nội bộ liên tục đọc từ hàng đợi của bạn và gọi hàm của bạn với các lô bản ghi. Hiểu cách cấu hình trình thăm dò này rất quan trọng để tối ưu hóa việc xử lý tin nhắn trong kiến trúc hướng sự kiện của bạn.

Cấu hình ánh xạ nguồn sự kiện kiểm soát cách Lambda đọc, xử lý và xóa tin nhắn khỏi hàng đợi. Các yếu tố liên quan nhất là:

• Kích thước lô (Batch size): số lượng bản ghi tối đa để gửi đến hàm trong mỗi lô. Thời gian chờ của hàm của bạn phải cho phép đủ thời gian để xử lý toàn bộ lô.
• Cửa sổ lô (Batch window): thời gian tối đa để thu thập bản ghi trước khi gọi hàm, tính bằng giây. Cửa sổ lô hoạt động như một cơ chế hết thời gian chờ. Lambda sẽ đợi tối đa thời lượng cửa sổ được chỉ định để thu thập tin nhắn cho đến khi nó đạt đến giới hạn kích thước lô hoặc hết thời gian cửa sổ, tùy điều kiện nào đến trước.
• Đồng thời tối đa (Maximum concurrency): số lượng hàm đồng thời tối đa mà nguồn sự kiện có thể gọi. Nó giúp ngăn hàm tiêu thụ tất cả khả năng đồng thời Lambda có sẵn của tài khoản và tránh các tin nhắn quay trở lại hàng đợi một cách không cần thiết do các hàm Lambda bị điều tiết.

Các giá trị được sử dụng trong các cài đặt này ảnh hưởng trực tiếp đến SLA đã được đặt để gửi thông báo như một yêu cầu kinh doanh. SLA càng ngắn (ví dụ: gửi thông báo trong vòng 30 giây so với 5 phút), nó sẽ tiêu thụ càng nhiều tài nguyên. Mức tiêu thụ tài nguyên cao hơn thể hiện ở nhiều lần thực thi đồng thời hơn, kích thước lô lớn hơn và cửa sổ lô ngắn hơn để xử lý tin nhắn đủ nhanh để đáp ứng cam kết.

Sau khi đã thiết lập các chi tiết cấu hình, hãy cùng xem xét việc triển khai logic kinh doanh để gửi thông báo qua các kênh email và thông báo đẩy. Đoạn mã giả sau đây minh họa cơ chế gửi thông báo:

exports.handler = async (event) => {
    for (const record of event.Records) {
        try {
            const paymentEvent = JSON.parse(record.body).detail;
            const eventType = paymentEvent.type;
            const invoice = paymentEvent.data.object;
            // Get customer details for notifications
            const customerDetails = await getCustomerDetails(invoice.customer);
            const paymentInfo = {
                amount: formatAmount(invoice.amount_paid, invoice.currency),
                customerEmail: customerDetails.email,
                isSuccess: true
            };
            // Set payment information based on type  
            switch (eventType) {
                case 'invoice.paid':
                    paymentInfo.paymentDate = new Date(invoice.created * 1000).toLocaleDateString();
                    break;
                case 'invoice.payment_failed':
                    paymentInfo.attemptCount = invoice.attempt_count;
                    paymentInfo.isSuccess = false;
                    break;
            }
            // Generate content for each notification type and process accordingly
            const email = generateEmailContent(customerDetails, paymentInfo);
            const pushNotificationContent = generatePushNotificationContent(customerDetails, paymentInfo);
            await Promise.allSettled([
                sendEmailNotification(customerDetails, email),
                sendPushNotification(customerDetails, pushNotificationContent)
            ]);
        } catch (error) {
            console.error('Failed to process recurrent payment:', {
                messageId: record.messageId,
                error: error.message,
                body: record.body
            });
        }
    }
};

Đoạn mã này cho thấy cách:

• Xử lý các lô SQS bằng cách lặp qua nhiều bản ghi.
• Phân tích cú pháp các sự kiện từ EventBridge.
• Định tuyến theo loại sự kiện để xử lý các kịch bản khác nhau.
• Xử lý lỗi một cách linh hoạt để xây dựng các hệ thống chịu lỗi.

Hãy nhớ rằng đây không phải là mã sẵn sàng sản xuất. Ví dụ, đối với sản xuất, bạn có thể muốn gửi các bản ghi lỗi đến hàng đợi dead letter hoặc hệ thống giám sát cảnh báo.

Hệ thống thông báo thanh toán định kỳ này cho thấy các tổ chức có thể tận dụng hiệu quả các sự kiện của bộ xử lý thanh toán để xây dựng các giải pháp tự động, có khả năng mở rộng. Bằng cách kết hợp khả năng định tuyến của EventBridge với độ tin cậy của SQS và tính toán phi máy chủ của Lambda, bạn đã tạo ra một hệ thống mạnh mẽ đáp ứng các yêu cầu về thời gian trong khi vẫn tiết kiệm chi phí và không cần bảo trì.

Dựa trên các mẫu hướng sự kiện này, hãy cùng khám phá cách các phương pháp kiến trúc tương tự có thể được áp dụng để tạo ra các chương trình khách hàng thân thiết động nhằm thúc đẩy sự tương tác và giữ chân khách hàng.

Chương trình khách hàng thân thiết

Theo Harvard Business Review, việc thu hút khách hàng mới tốn kém gấp 5 đến 25 lần so với việc giữ chân khách hàng hiện có (https://hbr.org/2014/10/the-value-of-keeping-the-right-customers), khiến các chương trình khách hàng thân thiết trở nên quan trọng đối với sự tăng trưởng bền vững. Các hệ thống khách hàng thân thiết truyền thống thường dựa vào xử lý hàng loạt để tính toán phần thưởng hàng giờ hoặc hàng ngày sau khi mua hàng, bỏ lỡ các cơ hội quan trọng để tương tác ngay lập tức với khách hàng khi sự hài lòng khi mua hàng ở mức cao nhất.

Các chương trình khách hàng thân thiết hướng sự kiện giải quyết thách thức này bằng cách phản ứng tức thì với các sự kiện của bộ xử lý thanh toán. Sau một giao dịch thành công, sự kiện thanh toán ngay lập tức kích hoạt tính toán khách hàng thân thiết, đánh giá tiến trình cấp bậc và gửi thông tin liên lạc được cá nhân hóa. Cách tiếp cận thời gian thực này cho phép các nhà bán lẻ cung cấp sự công nhận phần thưởng kịp thời và tạo ra trải nghiệm khách hàng hấp dẫn nhằm thúc đẩy việc mua hàng lặp lại.

Hình 11. Quy trình chương trình khách hàng thân thiết

Theo cấu trúc tương tự của ví dụ thanh toán định kỳ, hãy cùng xem một nhà bán lẻ hư cấu tên là Umbrella Corporation có thể xây dựng một dịch vụ khách hàng thân thiết mới với các yêu cầu sau:

• Tích lũy điểm tức thì dựa trên số tiền mua hàng và danh mục sản phẩm:
  • Quy tắc kinh doanh cho chương trình phần thưởng: 1 điểm cho mỗi đô la chi tiêu, 2x điểm cho các mặt hàng cao cấp và 3x điểm trong thời gian khuyến mãi.
• Tiến trình cấp bậc theo thời gian thực với thông báo trạng thái VIP ngay lập tức
  • Hệ thống đánh giá tiến trình cấp bậc bằng cách sử dụng ngưỡng điểm (Bạc ở 1.000 điểm, Vàng ở 5.000 điểm, Bạch kim ở 15.000 điểm) và kích hoạt thông báo phần thưởng.
• Các chiến dịch email được cá nhân hóa được kích hoạt bởi các mốc chi tiêu.
• Tự động áp dụng các khoản giảm giá đã kiếm được vào tài khoản khách hàng.

Dựa trên tích hợp EventBridge, bạn sẽ triển khai kiến trúc khách hàng thân thiết sau:

Hình 12. Sơ đồ kiến trúc chương trình khách hàng thân thiết

Đây là những quyết định phù hợp nhất:

• AWS Step Functions. Mặc dù các hàm Lambda xử lý khách hàng thân thiết một cách độc lập, việc điều phối các quy trình khách hàng thân thiết phức tạp với Step Functions mang lại một số lợi thế chính:
  • Điều phối quy trình làm việc: Step Functions quản lý toàn bộ hành trình khách hàng thân thiết từ tính toán điểm đến đánh giá cấp bậc và phân phối phần thưởng. Điều này đảm bảo mỗi bước thực hiện theo đúng trình tự và xử lý lỗi một cách linh hoạt với các cơ chế thử lại tích hợp sẵn.
  • Quản lý trạng thái: Dịch vụ duy trì trạng thái quy trình làm việc qua nhiều bước. Điều này giúp theo dõi tiến trình của khách hàng thông qua đánh giá cấp bậc, thông báo phần thưởng và các chiến dịch theo dõi mà không yêu cầu các lớp bền vững bổ sung để điều phối quy trình làm việc.
  • Xử lý lỗi và giám sát: Step Functions cung cấp giám sát quy trình làm việc trực quan và xử lý lỗi tự động, giúp dễ dàng xác định các nút thắt cổ chai trong quá trình xử lý khách hàng thân thiết và triển khai các chính sách thử lại tinh vi.
• Amazon DynamoDB. Các cơ sở dữ liệu quan hệ truyền thống có thể lưu trữ dữ liệu khách hàng thân thiết, nhưng DynamoDB cung cấp những lợi thế cụ thể cho việc xử lý khách hàng thân thiết theo thời gian thực:
  • Các hoạt động nguyên tử: Các hoạt động tăng nguyên tử của DynamoDB đảm bảo số dư điểm vẫn nhất quán ngay cả khi nhiều giao dịch xảy ra đồng thời cho cùng một khách hàng, ngăn chặn các điều kiện tranh chấp dẫn đến tính toán khách hàng thân thiết không chính xác.
  • Khả năng mở rộng tích hợp sẵn: nó tự động xử lý các đợt tăng lưu lượng truy cập trong thời gian khuyến mãi hoặc bán hàng theo mùa mà không cần can thiệp thủ công, đảm bảo việc xử lý khách hàng thân thiết vẫn phản hồi nhanh trong thời gian cao điểm kinh doanh.

Quy trình làm việc (hoặc máy trạng thái) sẽ xử lý logic phức tạp một cách không đồng bộ, có thể mất từ vài giây đến vài phút tùy thuộc vào đường dẫn được chọn. Một hàm Lambda tiêu thụ các sự kiện từ EventBridge theo thời gian thực, tính toán điểm khách hàng thân thiết và gửi thông tin đến quy trình làm việc trong Step Functions để xử lý không đồng bộ. Điều này đảm bảo điểm cập nhật tức thì (<200ms) trong khi các cải tiến tiếp theo trong chương trình khách hàng thân thiết, cập nhật dịch vụ hạ nguồn và liên lạc qua email, xảy ra theo thời gian của chúng. Bên cạnh đó, các vấn đề trong bất kỳ hoạt động không đồng bộ nào trong số này sẽ không ảnh hưởng đến trạng thái điểm hiện tại của khách hàng. Trong ví dụ này, có một điểm vào có điều kiện dựa trên sự thay đổi trạng thái cấp bậc, một sự tương tác có giá trị cao hoặc một sự tương tác mặc định.

Hình 13. Sơ đồ kiến trúc chương trình khách hàng thân thiết

Phần sau đây trình bày chi tiết các bước cấu hình thông qua AWS Management Console.

Amazon EventBridge

Thực hiện các bước tương tự như trong trường hợp sử dụng trước, nhưng lần này quy tắc chỉ đăng ký sự kiện bao gồm các khoản thanh toán một lần. Đây là mẫu sự kiện kết quả:

{
  "source": [{
    "prefix": "aws.partner/{your-payment-processor}"
  }],
  "detail-type": [
    "payment.succeeded"
  ]
}

AWS Lambda

Hàm này xử lý từng sự kiện thanh toán, áp dụng các quy tắc kinh doanh cho chương trình phần thưởng: 2x điểm cho các mặt hàng cao cấp, 3x điểm trong thời gian khuyến mãi. Nó cũng cập nhật số dư khách hàng thân thiết trong DynamoDB bằng cách sử dụng các hoạt động nguyên tử để xử lý các giao dịch đồng thời một cách an toàn và kích hoạt quy trình làm việc của Step Functions một cách không đồng bộ.

Hãy xem một đoạn mã ví dụ cho hàm này:

exports.handler = async (event) => {
    try {
        // Extract payment data from EventBridge event
        const paymentData = extractPaymentData(event);
        console.log(`Processing payment for customer ${paymentData.customerId}, amount: ${paymentData.amount}`);
        // Calculate loyalty points based on business rules
        const pointsEarned = calculateLoyaltyPoints(paymentData.amount, paymentData.productCategory);
        // Update customer record in database
        const customerUpdate = await updateCustomerPoints(paymentData.customerId, pointsEarned);
        // Prepare workflow input for Step Functions
        const workflowInput = {
            customerId: paymentData.customerId,
            transactionAmount: paymentData.amount,
            pointsEarned: pointsEarned,
            previousTier: customerUpdate.previousTier,
            currentTier: customerUpdate.currentTier,
            tierChanged: customerUpdate.tierChanged,
            totalPoints: customerUpdate.totalPoints,
            productCategory: paymentData.productCategory,
            transactionId: paymentData.transactionId,
            timestamp: new Date().toISOString()
        };
        // Trigger Step Functions workflow for customer engagement
        const executionArn = await triggerCustomerEngagementWorkflow(workflowInput);
        console.log(`Successfully processed loyalty points for customer ${paymentData.customerId}`);
    } catch (error) {
        console.error('Failed to process loyalty points:', {
            error: error.message,
            event: JSON.stringify(event)
        });
    }
};

AWS Step Functions

Trong hệ thống khách hàng thân thiết, Step Functions điều phối các hoạt động tương tác với khách hàng dựa trên đặc điểm giao dịch. Máy trạng thái đánh giá các điều kiện và định tuyến đến các nhánh khác nhau (nâng cấp cấp bậc, mua hàng giá trị cao hoặc xác nhận tiêu chuẩn). Để tạo quy trình làm việc khách hàng thân thiết, hãy làm theo các bước sau:

1. Điều hướng đến AWS Step Functions console.
2. Chọn State machines trong bảng điều hướng bên trái và sau đó Create state machine.
3. Nhập một tên có ý nghĩa (chẳng hạn như dev-loyalty-workflow) và chọn Standard làm loại máy trạng thái (phù hợp cho trường hợp sử dụng này với các quy trình làm việc chạy dài). Chọn Continue.
4. Bạn hiện đang ở Workflow Studio trong tab Design. Chuyển sang Code và thay thế mã mặc định bằng định nghĩa quy trình làm việc của bạn bằng cách sử dụng Amazon States Language:

{
  "Comment": "Umbrella Loyalty Customer Engagement Workflow",
  "StartAt": "EvaluateEngagementType",
  "States": {
    "EvaluateEngagementType": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.tier_changed",
          "BooleanEquals": true,
          "Next": "TierUpgradeWorkflow"
        },
        {
          "Variable": "$.points_earned",
          "NumericGreaterThan": 500,
          "Next": "HighValuePurchaseWorkflow"
        }
      ],
      "Default": "StandardPurchaseWorkflow"
    },
    "TierUpgradeWorkflow": {
      "Type": "Parallel",
      "Branches": [
        {
          "StartAt": "SendTierUpgradeEmail",
          "States": {
            "SendTierUpgradeEmail": {
              "Type": "Task",
              "Resource": "arn:aws:lambda:region:account:function:dev-send-tier-upgrade-email",
              "Retry": [
                {
                  "ErrorEquals": ["Lambda.ServiceException", "Lambda.AWSLambdaException"],
                  "IntervalSeconds": 2,
                  "MaxAttempts": 3,
                  "BackoffRate": 2.0
                }
              ],
              "End": true
            }
          }
        },
        {
          "StartAt": "UpdateCRMProfile",
          "States": {
            "UpdateCRMProfile": {
              "Type": "Task",
              "Resource": "arn:aws:lambda:region:account:function:dev-update-crm-profile",
              "Retry": [
                {
                  "ErrorEquals": ["Lambda.ServiceException", "Lambda.AWSLambdaException"],
                  "IntervalSeconds": 2,
                  "MaxAttempts": 3,
                  "BackoffRate": 2.0
                }
              ],
              "End": true
            }
          }
        },
        {
          "StartAt": "GeneratePersonalizedOffers",
          "States": {
            "GeneratePersonalizedOffers": {
              "Type": "Task",
              "Resource": "arn:aws:lambda:region:account:function:dev-generate-tier-offers",
              "Retry": [
                {
                  "ErrorEquals": ["Lambda.ServiceException", "Lambda.AWSLambdaException"],
                  "IntervalSeconds": 2,
                  "MaxAttempts": 3,
                  "BackoffRate": 2.0
                }
              ],
              "End": true
            }
          }
        }
      ],
      "Next": "ScheduleFollowUpCampaign"
    },
    "HighValuePurchaseWorkflow": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account:function:dev-high-value-engagement",
      "Retry": [
        {
          "ErrorEquals": ["Lambda.ServiceException", "Lambda.AWSLambdaException"],
          "IntervalSeconds": 2,
          "MaxAttempts": 3,
          "BackoffRate": 2.0
        }
      ],
      "Next": "ScheduleFollowUpCampaign"
    },
    "StandardPurchaseWorkflow": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account:function:dev-standard-purchase-confirmation",
      "Retry": [
        {
          "ErrorEquals": ["Lambda.ServiceException", "Lambda.AWSLambdaException"],
          "IntervalSeconds": 2,
          "MaxAttempts": 3,
          "BackoffRate": 2.0
        }
      ],
      "End": true
    },
    "ScheduleFollowUpCampaign": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
      "Parameters": {
        "FunctionName": "arn:aws:lambda:region:account:function:dev-schedule-follow-up-campaign",
        "Payload": {
          "customer_id.$": "$.customer_id",
          "campaign_type.$": "$.current_tier",
          "delay_hours": 72,
          "task_token.$": "$$.Task.Token"
        }
      },
      "End": true
    }
  }
}

Quan trọng: Thay thế các giá trị giữ chỗ region và account trong các ARN của hàm Lambda bằng các giá trị cụ thể của bạn.

5. Chuyển sang tab Config. Trong Permissions, chọn Create new role.
6. Cấu hình ghi nhật ký và Thẻ là tùy chọn nhưng rất được khuyến nghị. Thực hiện theo chính sách của tổ chức bạn tại đây.
7. Chọn Create ở góc trên bên phải.

Đây là một ví dụ về logic và các hoạt động cần triển khai trong máy trạng thái của bạn. Gửi email chào mừng cho các cấp bậc mới, cập nhật hồ sơ khách hàng trong nền tảng tiếp thị hoặc lên lịch các chiến dịch theo dõi dựa trên hành vi mua hàng. Sửa đổi và điều chỉnh theo yêu cầu cho các trường hợp sử dụng của riêng bạn.

Thông qua việc xây dựng hệ thống khách hàng thân thiết này, bạn đã thấy cách kết hợp khả năng của EventBridge và Lambda với điều phối của Step Functions để tạo ra một hệ thống khách hàng thân thiết mạnh mẽ, mang lại giá trị tức thì cho khách hàng đồng thời cung cấp thông tin chi tiết về hành vi và hiệu quả tương tác của khách hàng. Là một lợi ích bổ sung, kiến trúc phi máy chủ tự động mở rộng quy mô trong các thời kỳ mua sắm cao điểm như Black Friday, trong khi thời gian phản hồi mili giây của DynamoDB đảm bảo khách hàng thấy số dư điểm được cập nhật ngay sau khi mua hàng. Vòng phản hồi thời gian thực này giúp tăng tỷ lệ tương tác của khách hàng và giá trị đơn hàng trung bình khi khách hàng nhận thức rõ hơn về tiến trình của họ đối với phần thưởng.

Kết luận

Kiến trúc thanh toán hướng sự kiện được cung cấp bởi Amazon EventBridge đại diện cho một sự phát triển đáng kể so với các tích hợp dựa trên webhook truyền thống. Bằng cách tận dụng tích hợp EventBridge gốc với các bộ xử lý thanh toán được hỗ trợ, các doanh nghiệp đơn giản hóa hệ thống của họ và tập trung vào việc mang lại giá trị cho khách hàng. Hai mẫu kiến trúc được nêu trong hướng dẫn này cho thấy cách các phương pháp hướng sự kiện giải quyết các yêu cầu kinh doanh phức tạp trong khi loại bỏ nhu cầu về cơ sở hạ tầng webhook tùy chỉnh.

Đối với các tổ chức đang đánh giá các bộ xử lý thanh toán, hãy xem xét khả năng tích hợp EventBridge như một yếu tố chính trong quá trình ra quyết định của bạn. Khả năng tận dụng trực tiếp các dịch vụ hướng sự kiện của AWS cung cấp cho các tổ chức sự linh hoạt để thích ứng nhanh chóng với các yêu cầu kinh doanh và môi trường pháp lý thay đổi trong khi vẫn duy trì độ tin cậy và hiệu quả mà các doanh nghiệp hiện đại yêu cầu.

Để bắt đầu, khám phá tài liệu Amazon EventBridge, làm theo hướng dẫn này để cấu hình tích hợp bộ xử lý thanh toán của bạn và bắt đầu nhận các sự kiện của bạn.

Về tác giả

Israel Lopez Moriano
Israel là Kiến trúc sư Giải pháp cấp cao tại AWS, tư vấn cho các công ty khởi nghiệp và fintech về cách thiết kế các giải pháp đám mây có khả năng mở rộng cao, sáng tạo và an toàn. Ở nhà, anh ấy cố gắng áp dụng sự nghiêm ngặt tương tự vào thói quen đi ngủ của hai đứa con mình với kết quả không đồng đều.

Cristóbal Lopez Callejon
Cristóbal là Kiến trúc sư Giải pháp tại AWS có trụ sở tại Madrid. Anh ấy đam mê xây dựng các giải pháp sáng tạo bằng cách sử dụng các dịch vụ AWS để giúp khách hàng đạt được mục tiêu kinh doanh của họ. Ngoài công việc, bạn sẽ thấy anh ấy đi du lịch đuổi theo những con sóng và dành thời gian chất lượng với bạn bè & gia đình.

Jesús Bernal
Jesus là Kiến trúc sư Giải pháp cấp cao tại AWS ở Madrid, giúp các công ty khởi nghiệp xây dựng các giải pháp an toàn, có khả năng mở rộng với thời gian đưa ra thị trường nhanh chóng. Ngoài công việc, anh ấy đã từ bỏ bóng đá để điều hướng những cuộc phiêu lưu hàng ngày với hai cô con gái của mình.