Tác giả: Anton Aleksandrov và Debasis Rath
Ngày phát hành: 29 JAN 2026
Chuyên mục: Amazon EventBridge, Amazon Simple Queue Service (SQS), Announcements, AWS Lambda, Intermediate (200), Serverless

Để hỗ trợ các ứng dụng đám mây ngày càng phụ thuộc vào dữ liệu ngữ cảnh phong phú, AWS đã tăng kích thước payload tối đa từ 256 KB lên 1 MB cho các invocation hàm AWS Lambda không đồng bộ, Amazon Simple Queue Service (Amazon SQS) và Amazon EventBridge. Các nhà phát triển có thể sử dụng cải tiến này để xây dựng và duy trì các hệ thống event-driven giàu ngữ cảnh, đồng thời giảm nhu cầu về các giải pháp phức tạp như chia nhỏ dữ liệu (data chunking) hoặc lưu trữ đối tượng lớn bên ngoài.

Tổng quan

Các ứng dụng đám mây hiện đại dựa vào dữ liệu có cấu trúc, giàu ngữ cảnh để thúc đẩy hành vi thông minh. Các LLM prompt, tín hiệu telemetry, dữ liệu cá nhân hóa, ML output và nhật ký tương tác người dùng không còn là các chuỗi đơn giản. Thay vào đó, chúng thường là các đối tượng JSON hoặc YAML phức tạp, lồng ghép, mang ngữ cảnh có ý nghĩa. Trước đây, các nhà phát triển làm việc với các dịch vụ serverless như Amazon SQS, Lambda (invocation không đồng bộ và SQS event-source mapping), hoặc EventBridge phải quản lý dữ liệu của họ một cách cẩn thận để phù hợp với giới hạn kích thước payload 256 KB. Điều này thường có nghĩa là phải chia nhỏ các payload lớn hơn, đưa payload ra các object store bên ngoài như Amazon S3, hoặc sử dụng nén dữ liệu. Những giải pháp này đã làm tăng độ phức tạp và độ trễ, tạo ra các trường hợp biên khó giám sát và debug.

Với các bản phát hành gần đây, giờ đây bạn có thể truyền tải payload lên đến 1 MB, giảm đáng kể nhu cầu về chia nhỏ dữ liệu phức tạp và các giải pháp kiến trúc. Khả năng tăng cường này giúp hợp lý hóa các design pattern, giảm chi phí vận hành và làm cho các hệ thống event-driven trở nên trực quan hơn để xây dựng và duy trì. Các nhà phát triển giờ đây có thể bao gồm dữ liệu phong phú hơn trong một payload duy nhất—từ các LLM prompt chi tiết và trạng thái hệ thống đầy đủ đến ngữ cảnh toàn diện và lịch sử giao dịch hoàn chỉnh.

Giới hạn kích thước payload 1 MB mới áp dụng cho các invocation hàm Lambda không đồng bộ, cho dù bạn kích hoạt chúng bằng SQS event-source mapping, AWS Command Line Interface (AWS CLI), AWS SDKs, Lambda Invoke API, hoặc các dịch vụ AWS như EventBridge. Giới hạn tăng cường này cũng mở rộng cho tất cả các message và event chảy qua các Amazon SQS queue và EventBridge Event Buses.

Bắt đầu

Bạn không cần làm gì để bắt đầu. Cải tiến này được tự động áp dụng cho tất cả các hàm Lambda, SQS queue và EventBridge Event Buses mới và hiện có.

Nếu trước đây bạn đã chia nhỏ dữ liệu ở ngưỡng 256KB (hoặc thấp hơn), thì bạn có thể cần thực hiện thay đổi đối với cấu hình dịch vụ hoặc mã logic nghiệp vụ của mình để bắt đầu sử dụng giới hạn mới. Ví dụ: nếu bạn đã đặt thuộc tính MaximumMessageSize của Amazon SQS một cách rõ ràng, thì bạn có thể cần điều chỉnh nó thành một giá trị mong muốn mới. Payload lớn hơn cũng có thể dẫn đến chi phí cao hơn, như được mô tả trong phần tiếp theo.

Ví dụ thực tế: ngữ cảnh event phong phú trong kiến trúc event-driven agentic

Các kiến trúc event-driven cho phép các dịch vụ hoạt động độc lập mà không cần điều phối tập trung. Trong các hệ thống này, ngữ cảnh event toàn diện là điều cần thiết. Với giới hạn payload 1 MB tăng lên, các event giờ đây có thể mang dữ liệu toàn diện hơn—từ hồ sơ người dùng và chi tiết đơn hàng đến các tương tác lịch sử. Điều này cho phép các dịch vụ như inventory, shipping và notifications hoạt động tự chủ.

Hãy xem xét ví dụ sau. Trong ngành khách sạn và dịch vụ nhanh, sự hài lòng của khách hàng phụ thuộc vào việc phục hồi dịch vụ kịp thời, chu đáo. Khi khách gửi phản hồi tiêu cực thông qua khảo sát, đánh giá hoặc biểu mẫu khiếu nại, các nhóm dịch vụ phải thu thập ngữ cảnh, diễn giải vấn đề và soạn thảo phản hồi. Theo truyền thống, điều này có nghĩa là phải ghép nối thủ công các nhật ký chuyến thăm, dữ liệu khách hàng thân thiết và các khiếu nại trước đó. Giờ đây, điều này có thể được tự động hóa hoàn toàn bằng cách sử dụng một AI agent được cung cấp bởi các dịch vụ serverless của AWS và Amazon Bedrock, như được hiển thị trong hình sau.

Hình 1: Quy trình xử lý phản hồi của khách hàng

Quy trình làm việc:

1. Nhận: Một đánh giá mới được gửi thông qua ứng dụng Review và được phát ra dưới dạng một event đến EventBridge Event Bus.
2. Phát hiện: Event Bus gửi event đến Feedback analysis agent hạ nguồn. Agent chạy trong một hàm Lambda nhận dạng đánh giá là xếp hạng thấp hoặc khiếu nại.
3. Làm giàu: Agent thu thập metadata chuyến thăm của khách, chi tiết đặt phòng, hoạt động khách hàng thân thiết và lịch sử khiếu nại bằng cách sử dụng các công cụ MCP đính kèm vào một payload JSON có cấu trúc duy nhất (lên đến 1 MB).
4. Xếp hàng: Payload được gửi đến một SQS queue để xử lý không đồng bộ tiếp theo bởi các thành phần hạ nguồn.
5. Tạo: Một hàm Lambda riêng biệt thăm dò các message từ Amazon SQS và gọi một mô hình Amazon Bedrock để phân tích toàn bộ ngữ cảnh khiếu nại, soạn thảo một phản hồi cá nhân hóa, đề xuất một cử chỉ (chẳng hạn như hoàn tiền hoặc tín dụng) và phân loại mức độ nghiêm trọng của vấn đề.
6. Gửi: Message được ghi nhật ký và gửi đến khách hàng, và đến nhóm dịch vụ để phân tích thêm.

Trường hợp sử dụng này chứng minh tầm quan trọng của việc có một ngữ cảnh phong phú: chi tiết chuyến thăm hiện tại và trước đó, cấp độ khách hàng thân thiết, các tương tác trước đó và lịch sử phản hồi. Trước đây, các nhóm phải chuyển các phần ngữ cảnh sang Amazon S3 và tham chiếu chúng từ bên ngoài, làm tăng độ trễ và độ phức tạp kiến trúc. Kích thước payload 1 MB mới có nghĩa là tất cả thông tin này có thể được vận chuyển cùng nhau, cải thiện hiệu quả quy trình làm việc agentic serverless và hợp lý hóa việc bảo trì.

Các phương pháp hay nhất khi sử dụng payload lớn

Các phần sau đây phác thảo các phương pháp hay nhất mà bạn nên áp dụng khi sử dụng payload lớn hơn.

Cân nhắc về hiệu suất

Giám sát cẩn thận việc sử dụng bộ nhớ của hàm Lambda khi làm việc với payload lớn hơn, vì việc phân tích cú pháp và xử lý các đối tượng JSON phức tạp có thể làm tăng việc sử dụng bộ nhớ và thời gian thực thi. Kiểm tra kỹ lưỡng hệ thống của bạn dưới tải, đặc biệt đối với các ứng dụng có thông lượng cao, bằng cách benchmark với kích thước payload và mẫu lưu lượng truy cập thực tế. Mặc dù giới hạn payload đã tăng lên 1 MB, nhưng thời gian chờ 15 phút và giới hạn bộ nhớ của Lambda vẫn không thay đổi. Khi có thể, bạn có thể sử dụng nén để xử lý các tập dữ liệu lớn hơn một cách hiệu quả, nhưng hãy nhớ tính đến chi phí CPU bổ sung của việc nén và giải nén trong các tính toán hiệu suất của bạn. Đọc bài đăng Các phương pháp hay nhất để giám sát việc phân phối event với Amazon EventBridge để biết thêm các phương pháp hay nhất để điều chỉnh hiệu suất kiến trúc event-driven của bạn.

Hướng dẫn vận hành

Cấu hình dead-letter-queues (DLQ) để đảm bảo các message bị lỗi được giữ lại để kiểm tra và khắc phục sự cố. Điều này trở nên đặc biệt quan trọng với payload lớn hơn, vì việc debug các cấu trúc dữ liệu phức tạp đòi hỏi quyền truy cập vào ngữ cảnh message hoàn chỉnh. Triển khai xử lý lỗi và thử lại mạnh mẽ để quản lý các lỗi tạm thời, đặc biệt khi xử lý nội dung payload phong phú có thể chứa các cấu trúc lồng ghép hoặc các mối quan hệ phức tạp.

Để tối ưu hóa thêm thông lượng, bạn có thể nhóm các event nhỏ hơn tương tự lại với nhau thành một payload duy nhất. Tuy nhiên, tránh trộn lẫn các event không liên quan và duy trì ranh giới rõ ràng giữa các business domain và quy trình khác nhau.

Luôn đảm bảo rằng các dependency hạ nguồn của bạn có khả năng xử lý payload lớn hơn.

Khi nào nên sử dụng lưu trữ bên ngoài

Ngay cả với giới hạn payload 1 MB tăng lên, vẫn có những trường hợp mà các pattern như claim check vẫn là một lựa chọn kiến trúc hợp lý. Các pattern này liên quan đến việc lưu trữ một payload đầy đủ trong một hệ thống bên ngoài, chẳng hạn như Amazon S3, và truyền một tham chiếu nhẹ qua event stream của bạn. Cách tiếp cận này tiếp tục mang lại giá trị khi payload vượt quá giới hạn mới, khi dữ liệu cần được nhiều consumer sử dụng lại, hoặc khi có các yêu cầu nghiêm ngặt về governance, traceability và security. Ví dụ, audit logs, image metadata, hoặc các ML inference input lớn vẫn có thể vượt quá giới hạn 1 MB, ngay cả khi được nén. Thay vì mạo hiểm bị cắt bớt hoặc phân mảnh, claim check cho phép truy cập nhất quán, có thể mở rộng vào tập dữ liệu hoàn chỉnh.

Bạn có thể sử dụng các thư viện mã nguồn mở như Kafka sink connector cho EventBridge và Amazon SQS Extended Client Library (có sẵn cho Python và Java) để trừu tượng hóa sự phức tạp của việc lưu trữ các đối tượng lớn trong bộ nhớ ngoài.

Quản lý chi phí

Mặc dù payload lớn hơn cho phép ngữ cảnh phong phú hơn trong các ứng dụng của bạn, nhưng việc ghi nhật ký payload đầy đủ có thể làm tăng chi phí lưu trữ và xử lý. Các dịch vụ như CloudWatch Logs tính phí dựa trên khối lượng dữ liệu, do đó việc triển khai selective logging, payload truncation hoặc sampling trở nên quan trọng đối với các event có khối lượng lớn. Cân nhắc chỉ ghi nhật ký các trường thiết yếu hoặc triển khai các chiến lược sampling thông minh dựa trên tầm quan trọng của nghiệp vụ.

Để lưu trữ và giữ lại payload đầy đủ, hãy đánh giá các giải pháp lưu trữ hiệu quả về chi phí như Amazon S3 với các lifecycle policy phù hợp. Điều này có thể bao gồm việc chuyển các nhật ký cũ hơn sang các tầng lưu trữ rẻ hơn hoặc triển khai các quy trình dọn dẹp tự động cho dữ liệu không quan trọng. Cân bằng nhu cầu giữ lại của bạn với việc tối ưu hóa chi phí bằng cách xác định các policy rõ ràng về dữ liệu nào cần được giữ và trong bao lâu.

Xem lại các trang giá của AWS Lambda, Amazon EventBridge và Amazon SQS để tìm hiểu về chi phí phân phối và xử lý event và message.

Kết luận

Việc tăng kích thước payload tối đa từ 256 KB lên 1 MB cho phép các nhà phát triển xây dựng các kiến trúc phân tán hiệu quả hơn. Bạn có thể sử dụng cải tiến này để vận chuyển ngữ cảnh phong phú hơn trong payload event và message, giảm nhu cầu về các giải pháp phức tạp trước đây đã làm tăng độ phức tạp kiến trúc và chi phí vận hành. Không gian bổ sung này để truyền tải ngữ cảnh phong phú có nghĩa là bạn có thể hợp lý hóa quy trình làm việc của mình, cải thiện khả năng quan sát và giảm độ phức tạp kiến trúc cho dù sử dụng các pattern choreography hay orchestration.

Truy cập các hướng dẫn dành cho nhà phát triển của AWS Lambda, Amazon EventBridge và Amazon SQS để tìm hiểu thêm về cách tận dụng bản cập nhật này.

Để tìm hiểu thêm về kiến trúc serverless, hãy truy cập Serverless Land.