Updates to migration, potential improvements and:

Pundit feedback

jdom: We are using SQL Database mostly for the read model. There is only 1 CQRS BC (payments) that uses it for the write model. Should you include Azure Tables? Also, some of the read models are in Blob storage. Is this important to highlight?
Updated.

jdom: it's not possible nor advisable
Updated

jdom: more than addressing performance issues, I'd say designing for scalability, especially when dealing with high throughput I/O operations
Updated

jdom: "number of seats currently available" as shown by the read model, which is eventually consistent.
Changed

jdom: Should we call it Checkout screen instead of Registrant?
Agreed - changed.

jdom: sufficient seats available as shown by the read model
Done

jdom: typo: "to handle an transient errors"
Fixed

jdom: typo: The team plans to evaluated
Fixed

jdom: typo: handles
Fixed

jdom: that indicate that too (typo) many messages are being sent to a specific topic (not to a partition which can be ambiguous)
Fixed

jdom: We started using a subscription with sessions for the commands sent to SeatsAvailability. The reason is not ordering, as commands could be handled in any order. The reason is to guarantee a single writer per aggregate instance, so when scaling out we avoid tons of concurrency exceptions, as this is a high contention aggregate.In the past, because commands do not require ordering, we were not using subscriptions with sessions for commands.
Fixed

jdom: I'm not sure autonomy vs authority is reflected here, as the read model is always self contained by the BC (autonomous). Nevertheless, in order to optimize the calls to the DB for queries that will be performed very often, what we are doing here is embrace eventual consistency, but depending on the criticality of using very stale data, we decide how long (or if) to cache.
Removed callout

jdom: However, each bounded context uses a single SQL Database instance (not the entire system)
Fixed

jdom: We did implement dynamic throttling mechanisms per subscription or in the event publisher, but it would be good to have something that accounts for all of the subscriptions that belong to the same topic, or all data access for each of the databases or azure tables in general, as opposed to each of them responding to their limited view/information of transient errors
Modified

jdom: see the wat the EventStoreBusPublisher, SubscriptionReceiver and SessionSubscriptionReceiver uses the DynamicThrottling class that manages the degree of parallelism that it uses to send or receive messages.
Fixed

jdom: Is it SQL Database instead of Azure?
Changed

jdom: This is not correct, while the V2 web roles are up, there is a brief period of time when they get that message, but that is only the time it takes for us to set the mainteinancemode to false in the v2 worker role, and then set it to true in the V3 worker role. Let's ask Fernando to review this whole section, as there are some important details missing (like when does the replay of the messages happen, and there is also an in-house processor that will continue to update the V2 read models for a while, while the transition is happening)
This section has been re-written.

jdom8h ago
Now there are many more changes required to be done to PricedOrders and DraftOrders, so we will need to replay events, making this section stale.
Removed