# NFR Requirements Plan — Unit 03: Availability Module

Dit plan beschrijft de stappen voor het vaststellen van de non-functional requirements (NFR) voor de Availability Module (Unit 03).

## NFR Assessment Stappen
- [x] Vaststellen van de performance overhead van de Availability Middleware.
- [x] Definiëren van de betrouwbaarheidseisen voor de status check (bijv. caching).
- [x] Beveiligen van het onderhouds-bypass mechanisme.
- [x] Keuze van de opslag voor de dynamische status (Config vs Cache vs Database).

## NFR Vragen voor Unit 03

### 1. Performance
**Vraag 1.1**: Wat is de maximale toegestane latency die de Availability Middleware mag toevoegen aan elk request?
- A) **Ultra-laag**: < 1ms (vereist in-memory check zonder database/I/O).
- B) **Laag**: 1-5ms (staat een snelle cache of config check toe).
- C) **Gemiddeld**: < 10ms.

### 2. Status Opslag & Wijziging
**Vraag 2.1**: Hoe moet een beheerder de status van de API kunnen wijzigen in de MVP?
- A) **Static**: Alleen via `appsettings.json` (vereist herstart of config-reload).
- B) **Dynamic (In-Memory)**: Via een specifiek (beveiligd) endpoint dat de status in het geheugen aanpast (gaat verloren bij herstart).
- C) **Persistent**: Via de database, zodat de status over herstarts heen behouden blijft.

### 3. Caching
**Vraag 3.1**: Moet de resultaat van de beschikbaarheidscheck gecached worden in de middleware?
- A) Nee, altijd de actuele status ophalen via de service.
- B) Ja, voor een korte duur (bijv. 1 seconde) om performance te optimaliseren bij hoge belasting.

## Volgende Stappen
Na beantwoording van deze vragen worden de artifacts gegenereerd in `aidlc-docs/construction/availability-module/nfr-requirements/`.