We are introducing a master / slave replication schema in our web application. At certain scenarios we would prefer to explicitly direct reads to a slave and writes to the master, which to me is an obvious advantage of the schema.
Instinctually, I'd prefer for the switch to happen somewhere in the ORM, we use Doctrine and it offers a neat solution. But that's not really a solution for us, because we don't have a very practical way of distinguishing when a read is in reality a write (such as in update scenarios).
The next best thing would be to delegate the responsibillity for the switch to the controller and / or some custom libraries that in a cliche MVC approach could be considered as supercharged models. Although this is a very practical solution and probably the one that would require less time, I somehow fear there's something very important I'm missing and it will come back and bite me hard.
There are vague time constraints, and management support to feveresly refactor, but for this specific scenario we mostly agree that we should go with the practical approach, even if it means limit ourselves only where we've identifed the database as a major bottleneck.
To add to the confusion, I can't really say I'm experienced in replication schemes, when the issue was first discussed I thought a better solution would be to adopt a multi-master scheme, but when I started researching how easy those fail and how robust their implementation should be, it stopped feeling reasonable.