While an application-independent solution could be possible, in general, a replication-aware application could be much better, because you can use the high performance of asynchronous replication for most of the time, and only revert back to (slower) synchronous replication when it is needed.
This is not a theoretical method, we at Wikipedia use this model with specific code called "chronology protector", which only gets triggered when an important event happens (e.g. an edit) and you don't want the user to be served outdated results.
In order to do this, after doing your master writes, you should keep your master replication file and position (if not using GTID), or the GTID coordinates (if using GTID) after your write (once the transactions has been commited on the master), and then on the replica connections, wait until the server reaches those positions or higher. There is some extra details to consider, such as when exactly to wait (on write or on read), for how long until you give a timeout (e.g. if replica breaks or lags), but that is highly dependent on your environement.
In terms of implementation, MASTER_POS_WAIT()
/ WAIT_FOR_EXECUTED_GTID_SET()
are the functions commonly used for this.
Some of the clusters you mention give you shortcuts to perform this easier (e.g. Galera's causal reads), but the logic is similar- you don't want to be on fully consistent mode all the time; just forcing it when necessary.