While Zato can support AMQP, WebSphere MQ, ZeroMQ or FTP as well, the majority of environments will use the ubiquituous HTTP protocol only and this post describes the traffic patterns within a typical HTTP-only cluster consisting of a load-balancer, web admin, Redis, SQL ODB and two servers, right after it's been installed without any user-specific customizations.
Please refer to the Zato's architecture overview for a refresher on what role each of the components fulfills.
In order to ensure high-availability (HA), incoming HTTP traffic is always routed through a load-balancer that distributes the load in a fair manner across the servers so that outside client applications don't access the servers directly and are never concerned if any of the servers is unavailable.
SQL ODB (Operational Database), which as of Zato 1.1 needs to be either PostgreSQL or Oracle, stores information that benefits from being kept in a relational database, usually data that needs to be always saved on disk as promptly as possible and shouldn't be stored in RAM first, as with Redis.
Web admin is a GUI used to manage Zato environments. Being based on Django, it connects to SQL ODB in order to store a few parts of its configuration but the vast majority of its functionality is merely a frontend that connects to servers, through the load-balanacer, to invoke the public API servers expose.
In other words, this is a frontend only. Users are encouraged to use the API to create their own alternative frontend apps.
Arrowheads in the diagram represent the exact directions the traffic will follow - for instance, servers don't send messages to the load-balancer nor the latter will invoke Redis thus the arrows don't point in these directions.