Atelier: Art & Community

The problem

Sharing artwork looks simple until an upload fails, a cached response contains another person's state, or logout leaves a session active. I rebuilt Atelier to learn how system design handles those failures while keeping the app responsive.

What I built

• The full community workflow. An Angular interface and Express API for discovering artwork, publishing pieces, following artists, and saving favorites.
• A deliberate data split. MongoDB holds artwork documents; PostgreSQL owns accounts and relationships; object storage holds images. Redis caches derived reads and supplies queue hints.
• The infrastructure around those features. Revocable sessions, staged uploads, retryable cleanup, a SQL notification outbox, and CI checks for API, frontend, and database behavior.

Why I built it this way

• Give each store a clear responsibility. Artwork documents and transactional relationships have different access patterns. Explicit ownership keeps a cache or search projection from becoming an accidental source of truth.
• Publish in stages. SQL, MongoDB, and storage cannot share one transaction. Posts move through pending, written, and published states. Public reads hide unfinished work; reconciliation handles ambiguous failures.
• Cache shared content, then add private state. Redis reuses artwork and discovery responses. Likes and ownership flags are added per viewer afterward. Generation checks stop an old read from refilling a newly invalidated cache.
• Make logout a server decision. Short-lived access tokens and rotating refresh secrets remain subject to session revocation. Server-side role, ownership, and CSRF checks enforce access beyond the interface.
• Save side effects with the transaction. A like and its notification job commit together in PostgreSQL. A worker claims leased jobs and retries failures; a lost Redis hint does not lose the durable work.
• Bound work and test failure paths. Small connection pools, indexed queries, signed feed cursors, and request limits fit serverless constraints. CI exercises revocation, cache races, publication recovery, and queue behavior.

What I learned

I learned system design principles by applying them: data ownership, consistency, cache invalidation, authorization, and at-least-once processing. The main lesson was to define what survives a failure. Adding another service is useful only when its responsibility and recovery path are clear.