2026-05-27.aws-summit-ams.arc301.int-pat-dist-sys.pdf

Integration patterns for distributed systems

Today's applications are interconnected: they expose APIs, publish events, call third-party services, and externalize states. They must therefore address the fundamental challenges of distributed systems, such as out-of-order delivery, retries, idempotence, and partial failures. To address these challenges, architects must carefully evaluate integration options while considering how to manage complex system interactions. In this session, learn about common design trade-offs for distributed systems and how to navigate them with design patterns, illustrated by examples.

Transcript

1. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Sabarish Sekar he/him Solutions Architect Amazon Web Services Dirk Fröhner he/him Solutions Architect Amazon Web Services Integration patterns for distributed systems A R C 3 0 1
2. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. All photos by Dirk Fröhner
3. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. !In (modern) systems design, integration isn’t an afterthought, but an essential part of the application architecture and the software delivery lifecycle.
4. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Connecting two systems B Sync/async? Interaction model? Data format? Pub-sub or point-to-point? Conversation state? Error handling? Distributed? Partial failures? Retries? Idempotency? Backoff? Data or control flow? Polling? Systems or instances? A Messages vs. events? Dedicated vs. shared resources?
5. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. !No architecture decision comes without trade-offs - every decision brings some pain. Your job as software architect is to identify the least painful option on the table.
6. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed system fundamentals Coupling and its dimensions Delivery semantics and message order Control flow and flow control Multi-tenancy and shared resources Dependencies between systems Beyond data flow, pushing vs. pulling, How-often delivery, deduplication, FIFO Noisy neighbors, fairness in queues *incomplete, but relevant selection
7. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed system fundamentals Coupling and its dimensions Delivery semantics and message order Control flow and flow control Multi-tenancy and shared resources Dependencies between systems Beyond data flow, pushing vs. pulling, How-often delivery, deduplication, FIFO Noisy neighbors, fairness in queues
8. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed systems fundamentals Coupling and its dimensions Dependencies between systems
9. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Larry Constantine Author of Structured Design A structure is stable if cohesion is high, and coupling is low.
10. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Coupling – Integration’s magic word Interdependence between system components: a spectrum, not a binary state Decoupling* offers flexibility, but incurs cost in design and runtime B A
11. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Booking service Payment service e.g., HTTP connection Immediate response expected Conversation pattern Common pattern for APIs Requester waits till response is received Synchronous communication (APIs)
12. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Location Where? IP addresses, DNS, URIs Temporal When? Sync, async, availability Domain What? Name, Middlename, ZIP Format How? XML/JSON, AVRO, Binary Booking service Payment service Coupling with synchronous communication (APIs)
13. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Inventory service Booking service Customer loyalty service Payment service Coupling with synchronous communication (APIs)
14. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. https://... 202 Accepted https://... 202 Accepted https://... 202 Accepted Inventory service Booking service Customer loyalty service Payment service Asynchronous communication (APIs) Reduces temporal coupling
15. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Message queues • Queuing reduces location dependency • Queuing reduces timing dependency • Message passing generally reduces dependencies on interaction style and data format B A Message queue
16. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. • Queuing reduces location dependency • Queuing reduces timing dependency • Message passing generally reduces dependencies on interaction style and data format Message queues B A Message queue Amazon SQS Amazon MQ
17. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Inventory service Booking service Customer loyalty service Payment service Synchronous communication (APIs) Coupling with messages queues (before/after)
18. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Coupling with messages queues (before/after) • Synchronous communication (APIs) Inventory service Booking service Customer loyalty service Payment service Inventory service Booking service Customer loyalty service Payment service Async communication (message queues) Queue Queue Queue
19. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Inventory service Booking service Customer loyalty service Payment service Queue Queue Queue Do a payment! Add loyalty points! Find a ride! Domain coupling with message queues
20. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Inventory service Booking service Customer loyalty service Payment service Queue Queue Queue Review service Notification service ? Queue Queue Domain coupling with messages queues
21. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. B A • One-to-many • Delivers a copy of the message to every subscriber • Reduces domain coupling by embracing events • Examples: Amazon SNS & Kafka topics, Amazon EventBridge rules C Pub/Sub Publish-subscribe (pub/sub)
22. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. B A • One-to-many • Delivers a copy of the message to every subscriber • Reduces domain coupling by embracing events • Examples: Amazon SNS & Kafka topics, Amazon EventBridge rules C Pub/Sub Publish-subscribe (pub/sub) Amazon MSK Amazon SNS Amazon EventBridge
23. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Inventory service Booking service Customer loyalty service Payment service Async communication (message queues) Queue Queue Queue Do a payment! Add points! Find a ride! Domain coupling with pub/sub (before/after)
24. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Inventory service Booking service Customer loyalty service Payment service Async communication (message queues) Queue Queue Queue Do a payment! Add points! Find a ride! Inventory service Booking service Customer loyalty service Payment service Pub/sub Async communication (pub/sub) Ride booked! Domain coupling with pub/sub (before/after)
25. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Credits: Bernd Rücker – Practical Process Automation (O'Reilly Media 2021) Examples: Events, producer does not care about what happens, usually no response needed Decision to couple on the consumer Examples: Commands, producer wants X to happen, producer needs a response Decision to couple on the producer Messaging channel Payment service Payment service Booking service Booking service Messaging channel On which side do you want to couple?
26. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Do a payment! Booking received Queue https://... Synchronous response Queue Queue Pub/sub channel Resource management Customer loyalty service External payment service provider Payment service Booking service Why not both?
27. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed system fundamentals Coupling and its dimensions Delivery semantics and message order Control flow and flow control Multi-tenancy and shared resources Dependencies between systems Beyond data flow, pushing vs. pulling, How-often delivery, deduplication, FIFO Noisy neighbors, fairness in queues
28. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed systems fundamentals Control flow and flow control Beyond data flow
29. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Control flow versus data flow Data flow A B Control flow: RPC A B Control flow: Pull A B Control flow: Push A B
30. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Receiver Sender Control flow versus data flow C B A C B A Queue Control flow: Push Control flow: Pull Data and control flow can point in opposite directions
31. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. !Control flow influences dynamic system behavior, such as latency, scaling, batching, and time-outs.
32. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Queues are traffic shapers Arrival rate Consumption rate Arrival rate Consumption rate Queue empty Queue fills up Producer Consumer Queue
33. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Queues require flow control Back pressure: Slow down arrival rate Time to live (TTL): Shed old messages Fast producer Slow consumer TTL is an Amazon SQS setting; back pressure has to be built Even valuable messages have a meaningful time to live
34. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. !Queues decouple control flow, but require flow control.
35. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed systems fundamentals Control flow and flow control Pushing vs. pulling
36. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Ubiquitous architecture decision: push vs. pull • Sender owns integration logic (webhooks, legacy systems) • Enables routing, filtering, and error handling (DLQ) • Often provides rate limiting capabilities • Reduces idle (wasted) compute cycles (poll loops) • Enables real-time notifications Benefits of push-based integration Resource management Customer loyalty service Booking service Amazon EventBridge
37. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Ubiquitous architecture decision: push vs. pull • Consumer owns integration logic and rate • Enables queuing and load-leveling patterns • Simplified networking requirements • Unlocks stateful streaming analytics Benefits of pull-based integration Queue Payment service Booking service Amazon SQS Amazon MSK Stream events ! " #
38. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. At-a-glance Push Pull Sender owns integration logic (webhooks, legacy systems) Consumer owns integration logic Enables routing, filtering and error handling (DLQ) Enables queuing and load-leveling patterns Often provides rate limiting capabilities Consumer controls consumption (delivery) rate Reduces idle (wasted) compute cycles (poll loops) Simplified networking requirements Enables real-time notifications Unlocks stateful streaming analytics Ubiquitous architecture decision: push vs. pull
39. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed system fundamentals Coupling and its dimensions Delivery semantics and message order Control flow and flow control Multi-tenancy and shared resources Dependencies between systems Beyond data flow, pushing vs. pulling, How-often delivery, deduplication, FIFO Noisy neighbors, fairness in queues
40. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed systems fundamentals Delivery semantics and message order How-often delivery, deduplication
41. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Message delivery A message is delivered … at-most-once exactly-once at-least-once 0 .. 1 1 1 .. n !
42. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Retries and delivery semantics – Producer A A Broker 1 Broker 2 A A Store (reliable) 1 Acknowledge 2
43. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Retries and delivery semantics – Producer A A Messages are stored non-fault tolerant What is at-most-once? Broker 1 Broker 2 A Store (reliable) 1 Acknowledge 2 ?
44. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Retries and delivery semantics – Producer A Messages are stored non-fault tolerant Messages are not acknowledged (Fire & Forget or Timeout) What is at-most-once? Store (reliable) 1 ? ❌
45. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Retries and delivery semantics – Producer A Producer does NOT know if the message was received (or replicated) properly Messages are stored non-fault tolerant What is at-most-once? Store (reliable) 1 Messages are not acknowledged (Fire & Forget or Timeout) ?
46. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Retries and delivery semantics – Producer A Producer knows that the message was received (and replicated) properly Messages are stored fault tolerant Messages are acknowledged What is at-least-once? Acknowledge 2 A Store (reliable) 1
47. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Retries and delivery semantics – Producer A Messages might be delivered more than once due to producer retries ✅ Timeout A What is at-least-once? Store (reliable) 1 Acknowledge 2 Did A arrive? Let me retry! 3 ❌ A
48. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Retries and delivery semantics – Producer A Examples: Apache Kafka (Producer ID + Sequence), Amazon SQS (Deduplication ID & Window) Deduplication ID & state required Limited either by time-window or scope Timeout Do I know A already? ✅ Store (reliable) 1 Acknowledge 2 Did A arrive? Let me retry! 3 ❌ 4 What is exactly-once semantics (processing)? A
49. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. !Deduplication (of messages in distributed systems) is relative to a defined scope.
50. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed systems fundamentals Delivery semantics and message order FIFO (first in, first out)
51. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. A A Common with legacy systems (factories, POS, etc.) Throughput Latency B B C C D D Store (reliable) 1 Message order The easy way Acknowledge 2
52. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. B A A Batching, multi-threading, multi-producer Total vs partial order Causality (“happens-before”) B 12 3 9 6 " Message order The hard way
53. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. ✅ A1 A2 B A1 A2 B A1 A2 B ❌ ✅ Sharding with partition keys (streaming) or message groups (messaging) for scale Partial order generally sufficient “happens before”: necessary or desirable? 12 3 9 6 A2 A1 Ride 1 requested! Ride 1 cancelled! B Ride 2 requested! A1 B A2 ”Happens-before” Message order Partial order and causality (“happens-before” relationship)
54. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. !Order (of messages in distributed systems) is relative to a defined scope.
55. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Message order – after the fact A1 A2 PK SK Attributes A1 A2 Ride_1 v0 Latest: v2 Ride_1 v2 Status: cancelled Monotonic clocks (versions, generations, epochs, etc.)
56. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Message order – after the fact A1 PK SK Attributes A1 A1 Ride_1 v0 Latest: v2 Ride_1 v2 Status: cancelled Ride_1 v1 Status: requested Monotonic clocks (versions, generations, epochs, etc.)
57. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Message order – after the fact Monotonic clocks (versions, generations, epochs, etc.) PK SK Attributes A1 A1 Ride_1 v0 Latest: v2 Ride_1 v2 Status: cancelled Ride_1 v1 Status: requested Dup! Upsert or ignore
58. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed system fundamentals Coupling and its dimensions Delivery semantics and message order Control flow and flow control Multi-tenancy and shared resources Dependencies between systems Beyond data flow, pushing vs. pulling, How-often delivery, deduplication, FIFO Noisy neighbors, fairness in queues
59. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed systems fundamentals Multi-tenancy and shared resources Noisy neighbors and fairness in queues
60. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Simple booking web app flow 202 Accepted ... { < task & status representation > } POST /... HTTP/x.y ... { "tenant" : ..., "user" : ..., "what" : ..., "when" : ..., "where" : ... } Tenant i Tenant n … … <<Producer>> Booking submission <<Consumer>> Booking processing Message queue Tenant 1
61. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. A multi-tenant-queue (MTQ) for all tenants Producers Consumers Tenant 1 Tenant 2 Tenant 3 Booking preprocessing compute resources Booking processing compute resources
62. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. A multi-tenant-queue (MTQ) for all tenants Producers Consumers Tenant 1 Tenant 2 Tenant 3 Booking preprocessing compute resources Booking processing compute resources What if one tenant starts creating a large backlog of messages?
63. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. A multi-tenant-queue (MTQ) for all tenants Producers Consumers Tenant 1 Tenant 2 Tenant 3 Booking preprocessing compute resources Booking processing compute resources
64. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. A single-tenant-queue (STQ) for each tenant Tenant 1 Tenant 2 Tenant 3 Tenant 1 Tenant 2 Tenant 3 Producers Consumers
65. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. A broad spectrum 1 MTQ for n tenants n STQs for n tenants
66. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Cell sharding, multiple MTQs Cell 1 Cell 2 Cell 3 Cell 4 Tenant 1 Tenant 2 Tenant 3 Tenant 4 Tenant 5 Tenant 6 Tenant 7 Tenant 8 Producers Consumers Tenant =1 Tenant =2 Tenant=3 Tenant=4 Tenant=7 Tenant=6 Tenant=8 Tenant=5
67. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Cell 1 Cell sharding, multiple MTQs Cell 2 Cell 3 Cell 4 Tenant =1 Tenant =2 Tenant=3 Tenant=4 Tenant=7 Tenant=6 Tenant=8 Tenant=5 Tenant 1 Tenant 2 Tenant 3 Tenant 4 Tenant 5 Tenant 6 Tenant 7 Tenant 8 Producers Consumers
68. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Shuffle sharding, multiple MTQs Consumers 1 2 2 Tenant 1 Tenant 2 Tenant 3 Tenant 4 Tenant 5 Tenant 6 Tenant 7 Tenant 8 Producers
69. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2 1 Shuffle sharding, multiple MTQs Consumers 1 2 2 Tenant 1 Tenant 2 Tenant 3 Tenant 4 Tenant 5 Tenant 6 Tenant 7 Tenant 8 Producers
70. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2 1 Shuffle sharding, multiple MTQs Consumers 1 2 2 Tenant 1 Tenant 2 Tenant 3 Tenant 4 Tenant 5 Tenant 6 Tenant 7 Tenant 8 Producers
71. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2 1 Shuffle sharding, multiple MTQs Consumers 1 2 2 Tenant 1 Tenant 2 Tenant 3 Tenant 4 Tenant 5 Tenant 6 Tenant 7 Tenant 8 Producers
72. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Hybrid architecture with STQs and MTQs Multi-tenant main queue Dedicated queue for tenant 1 Tenant 1 Tenant 2 Tenant 3 Producers Consumers Tenant 1 All other tenants
73. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Dynamic producer-controlled overflow queues Multi-tenant main queue Tenant 1 Tenant 2 Tenant 3 Producers Consumers Consumers for all tenants
74. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Dynamic producer-controlled overflow queues Multi-tenant main queue Overflow queue for tenant 2 Regular consumers for non-noisy tenants Overflow consumers for noisy tenant >>> Tenant 2 is noisy >>> Tenant 1 Tenant 2 Tenant 3 Producers Consumers
75. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Dynamic consumer-controlled overflow queues Multi-tenant main queue Tenant 1 Tenant 2 Tenant 3 Producers Consumers Consumers for all tenants
76. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Dynamic consumer-controlled overflow queues Consumers for all tenants Multi-tenant main queue Overflow queue for tenant 2 <<< Tenant 2 is noisy <<< Tenant 1 Tenant 2 Tenant 3 Producers Consumers
77. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Dynamic consumer-controlled overflow queues Consumers balance between queues Multi-tenant main queue Overflow queue for tenant 2 <<< Tenant 2 is noisy <<< Tenant 1 Tenant 2 Tenant 3 Producers Consumers
78. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon SQS Fair Queues Dynamic consumer-controlled overflow queues Consumers for all tenants Tenant 1 Tenant 2 Tenant 3 Producers Consumers Multi-tenant main queue Overflow queue for tenant 2
79. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. !No architecture decision comes without trade-offs - every decision brings some pain. Your job as software architect is to identify the least painful option on the table.
80. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Distributed system fundamentals Coupling and its dimensions Delivery semantics and message order Control flow and flow control Multi-tenancy and shared resources Dependencies between systems Beyond data flow, pushing vs. pulling, How-often delivery, deduplication, FIFO Noisy neighbors, fairness in queues
81. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Please complete the session survey © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you Sabarish Sekar linkedin.com/in/ sabarishksekar Dirk Fröhner linkedin.com/in/ dirk-froehner