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

​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