If you have a strictly Design-Time CentraSite, you usually only need one CentraSite. Assuming you have Run-Time (Consumption) CentraSite instances to manage a PEP (Mediator), some of the considerations on whether to have CentraSite manage multiple Mediators or not are:
- isolation - this typically applies to Prod. You don’t want your non-production environment to be used to manage your production environment.
- mirroring production - most often Pre-Prod is intended to look as much like Prod as possible. With a CentraSite instance to manage and deploy Virtual Services to the run time (Mediator), the procedures in Pre-Prod will be closer to what will be done in Prod
- Mediator to CentraSite communication - if you have any of performance monitoring (SLA and/or throttling policies), event reporting, payload logging to CentraSite, these will involve Mediator sending data to CentraSite. Any environment that is used for performance testing may be impacted if other environments are co-hosted on the same instance. These activities (especially payload logging) can also impact the repository’s data store size very quickly and cause performance impact if not managed carefully with archive/purging processes. The OOTB purging processes are done per instance, so custom purge processes would be needed to purge by environment if different purge cycles are applicable by environment.
If you are working with older versions of CentraSite (below v9.5), a CentraSite instance per environment was helpful to manage naming, versioning and endpoints. With later versions, aliases, co-existing versions in Mediator and endpoint management have removed these considerations from the selection of instances to implement.