3.4 KiB
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
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
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
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 endpointWarning— 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
Execution Steps
- Step 1 — Analyze answers; flag ambiguities
- Step 2 — Generate
nfr-requirements.md - 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