4. Solution strategy

This chapter describes the fundamental architecture decisions made by the project team. These decisions shape the architecture of our product.

Container Diagram (C4-Model Level 2)

The container diagram shows how Tanker24 is structured internally without putting too big a focus on implementation details.

PlantUMLStructurizr

Technology decisions

As per organizational constraint OC-3 all relevant technology decisions need to be documented as architecture decision records (ADR). The following page lists all ADRs: here
To ensure the quality of the ADRs they use a shared comprehensive template.

Quality Goals

The following table maps the quality goals from Section 1.2 to concrete solution approaches implemented in the architecture.

Quality Goal	Scenario	Solution approach	Link to Details
Functional Stability	All main use cases must be covered.	Implement a unit and integration tests with pytest and Playwright E2E tests. CI pipeline enforces passing tests before merge.	Section 8.10
Reliability	The Tankerkoenig data API is unavailable.	Implement caching of station data in PostgreSQL to serve location information even without live price data.	Section 8.4
Reliability	The Tankerkoenig data API returns errors or times out.	Implement graceful degradation: catch exceptions, log them, return an empty station list without propagating 500 errors.	Section 6.1
Security	A user requests user-specific data.	Implement JWT-based authentication via fastapi-users library. All protected endpoints require a valid bearer token.	Section 8.2
Transferability	The user wants to export their data as JSON.	NestedExportDataService builds hierarchical JSON (cars → history records) and returns it with Content-Disposition header for download.	Section 5.2.2
Transferability	The user wants to export their data as a semicolon-separated CSV.	FlatExportDataService flattens data into CSV rows (one per history record) using Python's csv.DictWriter with semicolon delimiter.	Section 5.2.2