# NFR Design Plan — Unit 1: master-backend ## Unit Context **Unit**: `master-backend` **Input**: nfr-requirements.md, tech-stack-decisions.md, functional-design artifacts **Patterns to design**: Polly resilience pipeline, Data Protection wiring, background service isolation --- ## NFR Design Questions Answer each question by filling in your choice after the `[Answer]:` tag. --- ### Q1 — Data Protection: Injection Pattern `CmsInstanceService` needs to encrypt/decrypt `ApiKey` via `IDataProtector`. How should it be injected? A) **Direct `IDataProtectionProvider` injection** — inject `IDataProtectionProvider` in `CmsInstanceService`; call `.CreateProtector("SlpModularCms.Master.ApiKey")` in the constructor. Simple; no extra type; easy to test by mocking `IDataProtectionProvider`. B) **Thin `IApiKeyProtector` wrapper** — define a small `IApiKeyProtector` interface with `Protect(string)` and `Unprotect(string)` methods; inject the interface into `CmsInstanceService`. Purpose is explicit; makes mocking in tests trivially simple (no need to mock ASP.NET Core Data Protection internals). C) Other [Answer]: B --- ### Q2 — Polly Pipeline: Registration Scope The Polly resilience pipeline (exponential backoff + timeout) applies to all `SlaveApiClient` calls. How should it be registered? A) **Single pipeline on `AddResilienceHandler`** — configure one pipeline on the `IHttpClientBuilder` for `SlaveApiClient`; applies automatically to all HTTP calls made by this client. Zero per-call setup; consistent behavior across all slave endpoints. B) **Inline `ResiliencePipeline` per method** — build and execute a `ResiliencePipeline` explicitly inside each `SlaveApiClient` method. More control per call (e.g., different timeout for integrity check vs. status push); more boilerplate. C) Other [Answer]: A --- ### Q3 — `CmsInstanceService` Constructor Complexity `CmsInstanceService` will inject: `ICmsInstanceRepository`, `ISlaveApiClient`, `IDataProtectionProvider` (or `IApiKeyProtector`), `IOptions`, `IHttpContextAccessor`, `ILogger` — 6 dependencies. Is this acceptable? A) **Accept 6 dependencies** — follows existing project pattern (`PersistentAvailabilityService` has similar dependencies); no need to introduce aggregation objects. B) **Introduce `MasterServiceDependencies` context record** — wrap the 6 dependencies in a single record type to simplify the constructor signature. Cleaner constructor; slightly more indirection. C) Other [Answer]: B --- ## Execution Steps After all questions above are answered, the following artifacts will be generated: - [x] **Step 1** — Analyze all answers; flag any ambiguities - [x] **Step 2** — Generate `nfr-design-patterns.md` — Polly pipeline design, Data Protection pattern, logging pattern, test isolation pattern - [x] **Step 3** — Generate `logical-components.md` — infrastructure wiring diagram, component interaction for NFR patterns - [x] **Step 4** — Validate all Mermaid diagrams - [x] **Step 5** — Update `aidlc-state.md` - [x] **Step 6** — Present completion message for user approval --- *Artifact path*: `aidlc-docs/features/master-cms-module/construction/plans/master-backend-nfr-design-plan.md`