Caching Strategies:

When the application fetches automated room recommendations based on a user's specific schedule (their free time blocks), the caching layer must be incredibly fast but highly sensitive to state changes. In this case three main strategies are used:

• Persistent Key-Value Caching: Recommendations are stored in a local persistent database (SQLite/Drift for Flutter, Room/SQLite for Kotlin). The key is a composite string of the targetDate (e.g., "2026-04-25"), allowing fast retrieval of previously fetched results even when offline.

• Fast Retrieval & Fallback: When the user navigates or requests recommendations, the app retrieves results from local storage instantly if available. If the device is online, it fetches fresh data from the backend and updates the cache. If offline, it falls back to the cached result and informs the user that availability may have changed.

• Aggressive Invalidation (The Dependency Rule): The most critical rule for this cache is dependency invalidation. Because recommendations are strictly tied to the user's availability, any modification to the user's schedule (add, edit, or delete) must invalidate the recommendation cache. This ensures outdated availability data is not reused after schedule changes.

Eventual Connectivity Scenarios:

Title	Offline-First Schedule Editing and Synchronization
Event description	The user edits, adds, or deletes classes from their schedule while the device is completely offline.
System response	The application immediately updates the local schedule stored in the database to reflect the user actions and displays the updated schedule. Simultaneously, the specific sync actions are logged into a persistent database queue. Upon network restoration, the sync manager pushes the queued mutation actions to the backend sequentially, resolves any duplicate ids, and finally fetches the authoritative schedule to ensure synchronization with backend.
Possible antipatterns	• 4.6: The user creates a new manual class offline, but it disappears into the void because the app failed to persist it locally.• 5.2: The app fails to upload the pending class when internet is restored but stays completely silent, leaving the user unaware their schedule is out of sync.• 7: A class deletion fails while offline, and the class becomes permanently locked and undeletable even after the user reconnects to the internet.• 8.1: Adding a class offline sometimes safely queues the action, but other times simply throws a network exception randomly.• 9: The user taps the save button multiple times offline, queuing redundant classes that all duplicate on the backend upon reconnection.
Caching and retrieving strategy	5
Storage type	Kotlin: 1.b, 1.d | Flutter: 2.a
Stored data type	Kotlin: JSON formatted class payloads and action type strings | Flutter: Structured schedule data and queued mutation payloads

Local Storage:

The offline local storage strategies are applied when a user modifies their schedule, such as adding or deleting a class, while their device has no internet connection. In this situation, the application must immediately update the screen so the user sees their changes, while also securely saving those actions to be sent to the server once the connection is restored. To handle this smoothly, the schedule feature uses two main storage strategies:

• The first strategy is a local persistent database (SQLite/Drift for Flutter, Room/SQLite for Kotlin). This database stores a complete representation of the user's current schedule. When the user makes a change offline, the app instantly updates this local storage. The user interface reads directly from this database, meaning the screen updates immediately without needing to wait for a network response.

• The second strategy is a local database queue. Instead of storing the whole schedule again, this queue acts as a ledger that records each specific action the user takes. Every time a class is added or deleted offline, a new row is created containing the action type, the class details, and a timestamp. When the device regains internet access, a background process reads this database queue sequentially and sends each action to the server. Once the queue is fully synced, the app fetches the final, authoritative schedule from the server and updates the local database to ensure everything is perfectly aligned.