- Newest
- Most votes
- Most comments
Personally I would go with option 1 but have 2 deployment steps for each domain. So Domain A Step 1 for example does all the setup that makes Domain A a service used by other domains. All the "Step 1" stuff for all domains is done before moving on to Step 2. Domain A Step 2 for example does all the setup linking Domain A as a client of other domain services.
I would go with the 4th option: A centralized bus that everyone publishes to and subscribes on using filters. The limits you mentioned can be increased, so you can look into that.
Your Lazy doesn't seems like a good option. Decoupling the services means that the producers don't know about the consumers, or their subscriptions.
Do you really need FIFO capabilities? If you do, EventBridge is not an option for you.
I'll definitely look into the limits again, thanks!
As for the lazy subscription - what I meant was not for the producers to know the consumers but it could ease things for us if for example the topic subscription could've been using a dynamic arn.
We need the FIFO capabilities, mainly because of the deduplication and the ability to group messages by an id.
Thanks Uri.
Relevant content
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 4 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 9 months ago
Dividing the deployment into 2 steps, I like it :) but I think that this might have to involve some SDK calls from the Domain A Step 2 deployment process (for example to list the topics and see if the relevant ones are available).
Or have I missed anything? Thanks!