Interact network considerations

A production installation of Interact spans at least two machines. In a high-volume production environment, with several Interact runtime servers and distributed databases, your installation might span dozens of machines.

For best performance, there are several network topology requirements to consider.

If your implementation of the Interact API starts and ends sessions in the same call, for example:
```
executeBatch(startSession, getOffers, postEvent, endSession)
```
you do not need to enable session persistence (sticky sessions) between the load balancer and the Interact runtime servers. You can configure the Interact runtime servers session management for local cache type.
If your implementation of the Interact API uses multiple calls to start and end sessions, for example:
```
startSession
. . . 
executeBatch(getOffers, postEvent)
. . .
endSession
```
and you are using a load balancer for your Interact runtime servers, you should enable some type of persistence for the load balancer (also known as sticky sessions). If that is not possible, or if you are not using a load balancer, configure the Interact servers session management for a distributed cacheType. If you are using a distributed cache, all the Interact runtime servers must be able to communicate via multicast. You may need to tune your network so that the communication between Interact servers using the same multicast IP address and port does not impede system performance. A load balancer with sticky sessions has better performance than using a distributed cache.
Distributed caching among multiple server groups is not supported.
Keep your runtime environment Interact servers, Marketing Platform, load balancers, and touchpoint) in the same geographic location for best performance. Design time and runtime can be in different geographic locations, but expect a slow deployment.
Have a fast network connection (at least 1Gb) between the Interact production server group and its associated touchpoint.
Design time requires http or https access to runtime to complete deployment tasks. Any firewalls or other network applications must be configured to allow deployment. You may need to extend the HTTP timeout lengths between the design environment and the runtime environments if you have large deployments.
The contact and response history module requires access to the design time database (Campaign system tables) and access to the runtime database Interact runtime tables). You must configure your databases and network appropriately for this data transfer to occur.

In a testing or staging installation, you can install Interact design time and runtime on the same machine. This scenario is not recommended for a production environment.