# Services — Local Dev Master/Slave Setup

## No new domain services

This feature introduces no new business/domain service. All existing services are reused unchanged:

- **Master-side** (only present in `SlpModularCms.Api`, because only it references `Modules.Master`): `CmsInstanceService`, `SlaveApiClient`, `ApiKeyProtector` — manage registered CMS instances and communicate with them.
- **Slave-side** (present in both `SlpModularCms.Api` and `SlpModularCms.Api.Slave`, since both reference `Modules.Availability`): `MasterAvailabilityService`, `MasterApiKeyProtector` — accept and validate a master's per-instance API key.
- **Shared cross-cutting**: `IAuthService`, `IInvitationService`, `ISetupService` (from `Core.Identity` via `AddCoreInfrastructure`) — identical in both hosts.

## Orchestration Service

`ModuleOrchestrator` (relocated to `SlpModularCms.Core.Hosting`, see components.md) is the only "orchestration" element in this feature, and its role is unchanged: at startup, discover whichever module DLLs are present next to the host executable and wire them into DI + the request pipeline. Its behavior naturally differs between the two hosts only because of what's present in each host's build output — not because of any new conditional logic.

## Interaction Sequence — Local Master/Slave Connection Test

```mermaid
sequenceDiagram
    box rgba(246,224,94,0.4) Developer
      participant Dev as Developer
    end
    box rgba(99,179,237,0.4) Master Instance (5284/7221)
      participant MasterApi as SlpModularCms.Api
      participant CmsInstanceSvc as CmsInstanceService
    end
    box rgba(154,230,180,0.4) Slave Instance (5285/7222)
      participant SlaveApi as SlpModularCms.Api.Slave
      participant MasterCtrl as MasterController
    end

    Dev->>MasterApi: dotnet run --launch-profile master
    Dev->>SlaveApi: dotnet run --launch-profile slave
    Dev->>MasterApi: Open frontend, use Add CMS Instance dialog with slave URL
    MasterApi->>CmsInstanceSvc: Register CMS instance (slave URL + generated API key)
    CmsInstanceSvc->>MasterCtrl: Push registration / poll status using API key
    MasterCtrl-->>CmsInstanceSvc: Accepted, status healthy
    CmsInstanceSvc-->>MasterApi: Instance connected
    MasterApi-->>Dev: CMS Instance shows as Connected
```

Text alternative: The developer starts the master and slave backends on their respective ports, then uses the master frontend's existing Add CMS Instance dialog. The master's CmsInstanceService registers and communicates with the slave's MasterController using a per-instance API key, and the frontend reflects the resulting connected status.