I had been looking for an AF SDK alternative for determining the buffer system health. PIBufferStatus structure seems like a probable solution but I don't know when should I switch to the redundant environment.
Error & Critical status sounds like the one which can be used but its too generic. For e.g. if a point is not found in PI, then it's an error but that should not trigger the switch.
The Buffer Subsystem just buffers data while they cannot be forwarded to the PI System. There usually nothing wrong with continuing to write to the buffer queue because that's what it exists for.
PI Buffer Subsystem exposes some performance counters that can be used for monitoring. You can e.g. Total Queued Events using PI Interface for Performance Monitor to write that information to a PI Point and set up PI Notifications in case the queue is growing significantly.
With a redundant "data source", I would be more concerned about data collection issues because the data that was not collected at the time it was current, is usually not available anymore at later times. If you are in doubt about a failover case, let's discuss it. You can also learn from the way redundancy is implemented with OSIsoft Interfaces. Failover phase 2 is working pretty reliable. A failover pair communicates through a shared file and through PI Points to report different status information and what failover member assumes what status (active, standby ...).
I believe it is usually a good approach to start simple instead of trying to cover the most complex failover scenario one can imagine. For sure it makes sense to verify a failover strategy against theoretical failover scenarios and to as well perform some practical tests.