I have two small example charms I have used for debugging relation events in the past.
To facilitate your use case of multiple web servers and a reverse proxy, you would need to have the units of your webserver application charm set the information they want to communicate to the reverse proxy on the relation data. In this simple use case, the webserver units would set their listening hostname and port on the relation data.
This example provides interface does what you would want your web server charm to do, it sets the hostname and port of the listening web server process on it’s unit data in the relation_created event.
The other side of the relation would acquire the data set by the webserver units when data changes on the relation by observing the relation_changed event. The reverse proxy charm would then want to iterate over the webserver units of the related application grabbing the hostname and port of each, and write out the reverse proxy config once it gets the webserver data out of the relation.
event cycle docs
best practice for using relations with operator
operator framework docs