EventBridge 2.0
Making sure all event gets published on
Why
My Tradera Denormalizer
- Current solution for My Tradera scales badly
- We need more functionallity than can easily be implemented via Sql
- Long time storage
Current EventBridge
- Per message implementation
- No heads up if messages get added
- No heads up if messages get changed
- No serialization on time must be handled by subscriber, hard problem!
Solution
EventBridge 2.0
Responsibility
- Shift responsibility to publishers
- Make sure all events gets published
- Make sure changes fails our builds
Architecture sample Listing
Internal
Publisher
Internal
Publisher
Internal
Publisher
Internal
Publisher
MSMQ
Listing
EventBridge
RabbitMQ
EventArchiver
RabbitMQ
Topic exchange:
Tradera.Listing.Events
Routing
tradera.listing.eventbridge.events.auctioncreated.item
Leverage Routing
Pros:
- Flexibility
- Time serialization
- Scale out without raze conditions
-
Use well known messaging patterns:
- Competing consumers
- Selective Consumer
Cons:
- NSB like usage?
- Configuration inside rabbitmq
Message headers
All events:
- messageId
- 1c9668a1-6136-4669-bfb5-8d9449c8409e
- publishedTime
- 2016-09-02T11:41:43.7450822+02:00
- processCorrelationId
- 00000000-0000-0000-0000-000000000000
- itemId
- 85375437
- processService
- listing
- aggregateName
- item
- aggregateId
- 85375437
Process service specific:
- sellerMemberId
- 2023663
Message archiving
Topic exchange:
Tradera.Listing.Events
Routing
tradera.listing.eventbridge.events.auctioncreated.item
Coming later this fall!
Learnings
Inheritance makes
business intent hard
Exchanges are cheap
Low overhead for an exchange
Ownership
Messages are published from
questionable process services
Demo