Direct all read queries for entities that can be modified by a user to the leader and others to followers. A user can only modify her Twitter account, so any changes to her account such as adding or deleting tweets, profile changes, etc are always read from the leader. Since the writes were routed through the leader, the reads from the leader are always fresh and latest, thus ensuring read-after-write consistency.

Routing reads to the leader quickly falters when a user can potentially edit much of the dataset being replicated because the more and more reads will be directed to the leader and overwhelm it in the process. One mitigation is to note the time of the last write made by a user and for a certain time, say 30 seconds, after the last write, direct all reads to the leader. Thereafter the reads can be directed to the followers. Similarly, the replication lag on the followers can be measured and reads can be prevented from any follower that is 30 seconds behind the leader. Obviously, in this scheme the assumption is that after 30 seconds or whatever time durations you chose, all the followers have caught up with the leader.

Another option is for the user to note the timestamp of its last write and then query for reads only those replicas that have data at least up until the noted timestamp. Using the actual system clock for timestamp poses clock synchronization challenges and a monotonic increasing sequence number as a logical timestamp can be used instead.