- 최신
- 최다 투표
- 가장 많은 댓글
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.
관련 콘텐츠
- 질문됨 6달 전
- AWS 공식업데이트됨 일 년 전
- AWS 공식업데이트됨 2년 전
- AWS 공식업데이트됨 7달 전
- AWS 공식업데이트됨 10달 전
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!