89 lines
3.4 KiB
Markdown
89 lines
3.4 KiB
Markdown
# NFR Requirements Plan — Unit 2: slave-availability-extension
|
|
|
|
## Unit Context
|
|
|
|
**Unit**: `slave-availability-extension`
|
|
**Inputs**: domain-entities.md, business-logic-model.md, business-rules.md (Unit 2 FD)
|
|
**Key NFR concerns**: ApiKey storage security, static cache thread safety, test coverage, logging
|
|
|
|
---
|
|
|
|
## Questions
|
|
|
|
Answer each question by filling in your choice after the `[Answer]:` tag.
|
|
|
|
---
|
|
|
|
### Q1 — ApiKey Storage: How should the slave store the master's ApiKey?
|
|
|
|
The `MasterRegistration.ApiKey` is used to validate subsequent master calls (BR-SLAVE-02/04/06). How should it be stored in the DB?
|
|
|
|
A) **Plain text** — store as-is from the `X-Master-Api-Key` header. Simple; compare directly on each request. Acceptable given the key is an infrastructure credential (not user password) and the DB should be secured.
|
|
|
|
B) **SHA-256 hash** — store `SHA256(apiKey)` and compare `SHA256(incoming)` on each request. No plain-text at rest; constant-time comparison prevents timing attacks.
|
|
|
|
C) **ASP.NET Core Data Protection** — encrypt using `IDataProtectionProvider` (same pattern as `ApiKeyProtector` in Unit 1). Reversible; consistent with master-side pattern.
|
|
|
|
D) Other
|
|
|
|
[Answer]: C
|
|
|
|
---
|
|
|
|
### Q2 — Static Cache Thread Safety: How should `_masterIsAvailable` and `_masterDisableMessage` be protected?
|
|
|
|
These static fields are read on every request (high frequency) and written only when the master pushes status (rare). What thread safety approach is appropriate?
|
|
|
|
A) **`volatile` fields** — `private static volatile bool _masterIsAvailable = true` and `private static volatile string? _masterDisableMessage`. Sufficient for atomic single-field reads/writes in .NET; no lock overhead per request. Consistent with `PersistentAvailabilityService`'s existing circuit breaker pattern.
|
|
|
|
B) **`lock` statement** — lock a `static readonly object _lock` around both reads and writes. Explicit and safe; slight overhead on every request read.
|
|
|
|
C) Other
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
### Q3 — Test Coverage: What should be excluded from coverage in this unit?
|
|
|
|
Which components in Unit 2 should receive `[ExcludeFromCodeCoverage]`?
|
|
|
|
A) **Module/wiring only** — only the `AvailabilityModule` changes (service registrations, migration call) and EF migration files. All service, controller, and middleware logic is covered.
|
|
|
|
B) **Module + DTOs** — `AvailabilityModule` changes + DTO/request/response records + EF migration files. Consistent with Unit 1 pattern.
|
|
|
|
C) Other
|
|
|
|
[Answer]: B
|
|
|
|
---
|
|
|
|
### Q4 — Logging: What log levels apply to the new slave-side logic?
|
|
|
|
A) **Minimal** — only Error for unexpected exceptions. Keep logs quiet since master calls are frequent background operations.
|
|
|
|
B) **Structured per scenario** — follow the same table approach as Unit 1:
|
|
- `Warning` — API key mismatch on any endpoint
|
|
- `Warning` — master gate blocked a request (log path + disable message)
|
|
- `Information` — master registered successfully (first registration)
|
|
- `Information` — status update received (isAvailable value)
|
|
- `Debug` — get-registered-url called
|
|
|
|
C) Other
|
|
|
|
[Answer]: B
|
|
|
|
---
|
|
|
|
## Execution Steps
|
|
|
|
- [x] **Step 1** — Analyze answers; flag ambiguities
|
|
- [x] **Step 2** — Generate `nfr-requirements.md`
|
|
- [x] **Step 3** — Generate `tech-stack-decisions.md`
|
|
- [ ] **Step 4** — Update `aidlc-state.md`
|
|
- [ ] **Step 5** — Present completion message for approval
|
|
|
|
---
|
|
|
|
*Artifact path*: `aidlc-docs/features/master-cms-module/construction/plans/slave-availability-extension-nfr-requirements-plan.md`
|