The AWS Architecture Center describes event-driven architecture as using events to trigger and communicate between decoupled services.
The Particular Service Platform implements the publish/subscribe model, with each NServiceBus endpoint acting as a publisher (event producer) and/or subscriber (endpoint consumer).
Components
NServiceBus publisher (event producer)
Publishes events with business meaning in a reliable fire-and-forget style and has no knowledge of subscribers (there may be none).
NServiceBus subscriber (event consumer)
Subscribes to a specific event type and reacts to it. A subscriber may also be an event publisher, since processing an event may lead to publishing more events.
Amazon Simple Queue Service (SQS)
The messaging service that brings together publisher and subscriber creating a layer of abstraction between the two.
Challenges
Event ordering
Subscribers cannot rely on the order they receive published events, which may be affected by many factors such as concurrency, scaling, retries, partitioning, etc. Events and subscribers should be designed so that they do not rely on strict ordering to execute business processes.
Event payload size
Putting too much data on messages couples publishers and subscribers, defeating one of the main benefits of messaging in the first place. Bloated event contracts indicate sub-optimal service boundaries, perhaps drawn along technical constraints rather than business rules, or data distribution over messaging. Well-designed events are lightweight contracts, focusing on sharing IDs rather than data.
Technology choices
In event-driven architectures, components are decoupled, allowing choice of the most suitable compute and data store options for a specific component or set of components.
An event-driven approach requires support for the publish/subscribe model. NServiceBus supports this model for AWS SQS, independent of the underlying service capabilities.