Event-driven order processing
An event-driven order processing flow: a single API publishes OrderCreated, and downstream services subscribe to handle inventory reservation, payment, fulfilment, and customer notification independently.
Architecture previewEvent-driven order processing
Recreate this in Raltey
Copy this prompt
Paste this into Raltey's AI agent to generate the same diagram, then tweak it on the canvas.
Prompt
Create an event-driven architecture diagram for order processing. A client hits an Orders API. The API publishes an OrderCreated event to a topic. Four services subscribe: Inventory, Payment, Fulfilment, Notification. Each has its own database. Inventory, Payment, and Fulfilment each have a service-specific dead-letter queue for failures.
Context
- - One canonical event topic per business event.
- - Each downstream service is independently retried.
- - Failures land in service-specific DLQs.
Patterns
- - Fan-out from one canonical event.
- - Each subscriber retries independently.
- - Per-service DLQs preserve isolation.
Diagram structure
Nodes and connections
Clientactor
Orders APIservice
OrderCreated topicqueue
Inventory serviceservice
Payment serviceservice
Fulfilment serviceservice
Notification serviceservice
Inventory DBdb
Payment DBdb
Fulfilment DBdb
Inventory DLQqueue
Payment DLQqueue
Fulfilment DLQqueue
Connections
ClientOrders API
Orders APIOrderCreated topic
OrderCreated topicInventory service
OrderCreated topicPayment service
OrderCreated topicFulfilment service
OrderCreated topicNotification service
Inventory serviceInventory DB
Payment servicePayment DB
Fulfilment serviceFulfilment DB
Inventory serviceInventory DLQfailure
Payment servicePayment DLQfailure
Fulfilment serviceFulfilment DLQfailure
Notes from the field
- Use schema versioning on events to allow safe rollouts.
- Idempotent handlers required - the same event may be delivered twice.
- Run the notification service last (or in parallel) so failures there do not block fulfilment.
Frequently asked
Do I need a saga for refunds?
For coordinated multi-service rollbacks yes. Add a Refund saga that emits compensating events (InventoryRestocked, PaymentRefunded).
How do I prevent double charging?
Idempotency: include an event id, store processed ids in the payment DB, and reject duplicates at the handler level.
More templates
FlowchartSaaS onboarding email flowFlowchartCustomer support runbook flowFlowchartPayment webhook retry and error flowFlowchartGitHub PR review and merge flowFlowchartLogin with magic link flowArchitectureThree-tier SaaS architecture on AWSArchitectureMicroservices architecture on KubernetesArchitectureReal-time data pipeline on GCP
Open this template in Raltey
Edit it on the canvas, ask the AI agent to extend it, then share or export.
Start for free