Week 5: data ownership, consistency, and workflows
On Friday, 2 October 2026, you will decide how one action in your Citizen Services Portal handles data and failures. Checkpoint 1 is on Friday, 9 October.
This week's task
Choose one action from your Week 4 container diagram. For example, a citizen submits a case and opens its status page. Use one of your Week 3 quality attribute scenarios to justify your choices.
Edit the existing file docs/architecture.adoc:
In the Data management section
- Name the system that stores the official version of the key data. This is the data owner.
- Name any copies, such as a search index or cache, and say whether they can be out of date.
- Write one promise about what the citizen sees and when. Refer to one of the quality attribute scenarios your team wrote in Week 3 in
docs/qa_scenarios.adoc. Use its title so readers can find it.
In the Workflow and messaging section
- Describe what normally happens when the citizen takes the action.
- Describe one timeout or lost-reply case. State what the citizen sees and how your system checks the result or safely retries.
- Describe one test you would run to check this behavior.
Commit the updated docs/architecture.adoc to your team fork. Update the Week 4 container diagram too if your data-owner choice changes it. At the start of the practical session, bring one question about your architecture for the Checkpoint 1 discussion.
Example: case submission
Here is an example of the kind of entry to add to the two sections of docs/architecture.adoc. Use owners, targets, and behavior that fit your team's design.
Data management
- The portal case store owns case status. The search index holds a copy that may be out of date.
- Promise: when the case store is available, the citizen sees a confirmed case on the next status page within two seconds. A team could refer to its Week 3 scenario named "Case status visibility" in
docs/qa_scenarios.adoc. The status page reads from the case store or a copy that has caught up.
Workflow and messaging
- Normal path: the portal stores the case and returns its ID. The citizen sees the confirmed case on the status page.
- Lost reply: the portal stores the case. The reply is lost. The page shows "Checking submission" while the client retries with the same request ID. The retry returns the existing case.
- Test: drop the first reply and delay the search index. Check that one case exists and the next status page shows its confirmed status or temporary unavailability.
Another option: document sharing
Your team may choose a different action. For document sharing, the consent store could own revocation state while an application cache holds a copy. A promise could be that each new sharing request uses the current consent state. If the consent check times out, pause sharing and show temporary unavailability. Test by revoking consent just before a sharing request and delaying the cache.