Solution Overview

Solution Overview

Anichron follows a Clean Architecture approach with a shared core library. The separation keeps heavy media processing away from the responsive API.

Project structure

Project	Role
Anichron.Core	Single source of truth: domain models, AnichronDbContext, all Fluent API configuration, shared utilities (XXHash64, path parsing). Zero dependencies on other projects.
Anichron.Infrastructure	DI wiring; reads DB connection from POSTGRES_CONNECTION__* env vars or Docker secrets.
Anichron.API	ASP.NET Core Minimal APIs — read-only queries, DTO mapping, proxy file serving, originals on demand. All routes prefixed /api/v1/.
Anichron.Worker	BackgroundService — NAS crawling, EXIF extraction, FFmpeg transcoding, proxy generation, reconciliation. Bound to one user via WORKER__USER; auto-creates UserStorageConfig on startup.

The Worker is the only database writer. All inserts, reconciliation, burst detection, and soft-deletes happen here. The API is strictly read-only.

Containers

Container	Base image	Responsibility
anichron-db	postgres:17-alpine	Persists metadata, user configs, and asset relationships
anichron-api	mcr.microsoft.com/dotnet/aspnet:10.0-alpine	REST endpoints — read-only access to DB, NAS, and proxy storage
anichron-worker	mcr.microsoft.com/dotnet/runtime:10.0-noble	Media processing — read-only NAS access; read-write proxy storage; GPU drivers on amd64

One Worker container per user. See Self-Hosting for multi-user setup.

Storage layout

Path	Mount	Used by
/data/originals (NAS)	:ro	API (on-demand originals) + Worker (crawling) — originals are never modified
/data/proxies (SSD)	:rw Worker / :ro API	Worker writes proxies; API serves them

Proxy files use a two-level shard path: /data/proxies/{id[0:2]}/{id[2:]}/{type}. See Engineering Decisions for the rationale.