I am using a CQRS style pattern (No Event Sourcing) I simply separate my reads and writes into 2 separate application boundaries.
Right now, the application works against one SQL 2008 Database. I would like to add multiple read databases to distribute the workload as volume is starting to get high.
I need a solution in SQL 2008 where I can update a single database, and have the changes replicated/propigated in real-time to other nodes. This only needs to be a one-way propagation as the application will only be writing to a single “master” database.
I have read about peer-to-peer transactional replication. Anyone who has used that, how much latency is there in updating the child nodes?
Any other solutions?
If you’re not using event sourcing on the domain/command side, that’s fine. But that shouldn’t necessarily prevent you from storing all events on the read side in some kind of “events” table. In doing this, it allows you to destroy your view model tables and rebuild from all events stored in the “events” table within your read model database.
The reason for this is to scale your read side. As your existing read DB comes under pressure and can no longer sustain the load, rather than trying to replicate from a master “read database”–simple create another database instance on some other hardware that populates itself from the “events” table. Then have this additional read database subscribe to the events generated by your domain. (Once you understand what’s happening, you’ll actually want to subscribe first and then populate the table so that you don’t miss events that are published)
This allows you to have two read databases that are siblings but which don’t talk to each other. They simply listen to events from the domain, update the read model tables, and add the received events to some kind of local “events” table.