From the eShop (AdventureWorks), mapped as three services architecture map
Order-status updates only reach shoppers on the WebApp process that handled the event
Order Status Notification Service is a singleton (Extensions.cs:26) that keeps subscriptions in an in-memory dictionary keyed by buyer id. All six RabbitMQ order-status handlers, such as OrderStatusChangedToPaidIntegrationEventHandler, call NotifyOrderStatusChangedAsync on it, and it wakes only the circuits subscribed in that same process. The event handlers have no other way to reach a buyer's open circuits.
Impact: With more than one WebApp replica behind a load balancer, a shopper whose browser circuit is on a different instance than the one that processed the RabbitMQ event never gets the live status refresh — their Orders page only updates on a manual reload.
Recommendation (medium effort): Replace the in-process subscription dictionary with a mechanism that fans out across replicas — a SignalR backplane, Redis pub/sub, or routing the notification through the message bus so every instance can push to its own local circuits.
The trail
- Components
- Order Status Notification Service
- Order Status Event Handlers
- Service Registration
- Order Status Refresher
More from this board
- Identified Command swallows a failed CreateOrder and still reports success on retry
- An unreachable embedding model blocks product price changes
- Failed catalog price-change events are marked failed and never retried
- Order Queries reads straight from the write side's OrderingContext, not a separate read model
- RabbitMQ status handlers skip the idempotency check HTTP commands get
- Awaiting-validation stock check confirms orders for unknown product ids
- A rejected order still empties the shopper's bag
- A retired catalog item breaks Cart Menu's basket load everywhere