The below graphic demonstrates general information flow through the rets.ci infrastructure. For each Subscription at least two perpetual Node.js services are started - Poller and a Pusher. Poller checks an MLS periodically for changes. It uses the Subscriber's RETS credentials, acting on their behalf. The Pusher consumes change messages, and handles ensuring their are delivered to the the client's web site.
Typical "update" flow:
- Some real estate agent adds a new listing to the MLS, or perhaps lowers the listing price of a property.
- Poller service dedicated to monitoring this particular MLS on behalf of a particular client, detects the change, it sends an AMQP message to a RabbitMQ exchange dedicated to the specific MLS.
- Pusher, which so far hasn't done anything, subscribes to the MLS message queue to be aware of all changes that are happening to the MLS. Once Pusher sees a new message, it starts preparing for sending an update message to the WordPress blog.
- The WordPress blog receives some update from Pusher and the site, and data in the MySQL database, is immediately up-to-date.
- Although not noted here, each client also has an Elasticsearch index that contains a full replica of the property listings that exist on their site.
Property Document Update Workflow
Below we demonstrate the typical "workflow" of information and how how the typical "property document" is transformed and prepared for the end-client's software.