Production Marketplace Platform

Summary

I designed and delivered a production marketplace platform for public discovery, protected management workflows, media intake, and asynchronous operational work. The system is a single server-rendered application and API backed by relational persistence, caching, object storage, and an isolated worker tier. It has been operating since March 2026.

Context

The product needed a public-facing discovery experience without exposing sensitive account and operational workflows. The application had to accept user-generated media and run recurring operational work that must not compete with interactive requests. The controls below are described by category; configurations, thresholds, providers, and endpoints stay private.

Role

Sole developer responsible for architecture, implementation, delivery, and the production system around it: the request path, the identity integration, the media pipeline, the worker tier, and the observability that keeps them legible.

Architecture

A single process composes the server-rendered frontend and the API: the same runtime serves rendered pages and the routes behind them, which keeps one deployment, one security posture, and one set of shared clients. Behind it sit four kinds of state (a relational database, a cache, object storage, and a queue), and every one of them is reached through services rather than from controllers directly.

System context / public case study

One SSR + API process over shared state

The rest of this case study walks the paths that matter: how a request is hardened, how a session is established, how background work is kept off the request path, how media is taken in, and how usage is measured without a write per view.

Request path and hardening

Before any handler runs, a request clears a fixed sequence of gates composed at the server’s root: transport security and response headers, identity, abuse controls, and schema validation. A handler only ever sees input that has already been authenticated and parsed, and it returns a projected view of the data rather than a raw record.

Request path / edge to handler

The gates a request clears before a handler runs

Authentication and session

Identity uses the OAuth 2.0 authorization-code flow against an external OIDC provider. The redirect carries a state value that is checked on return with a constant-time comparison; the returned token is verified against the provider’s rotating signing keys, with issuer, audience, and expiry all enforced before it is trusted. The session then lives in a signed, http-only cookie, and the user record it maps to is resolved cache-first.

Authentication / OAuth 2.0 authorization code

From a guarded route to a resolved session

Session resolution is where the cache earns its place: a token maps to a user id, and the user id maps to a cached user record, so a signed-in request rarely touches the database to know who is asking. Logout and account changes flush every token mapped to that user, so a stale session cannot outlive the record behind it.

Asynchronous work and queue isolation

Recurring and deferred work (notifications, content processing, the telemetry flush, and data-retention cleanup) runs in a separate worker process against a dedicated Redis instance, distinct from the Redis the request path uses for cache and sessions. This is the platform’s central operational decision.

Asynchronous work / broker isolation

Background work never shares the request path's Redis

Splitting the broker from the cache means a burst of background jobs cannot evict a hot cache or starve session lookups, and the worker can be restarted, scaled, or fail without taking request handling down with it. The cost is real: two Redis roles to run, a second process to supervise, and jobs that are eventually, not immediately, consistent. For work that no user is blocking on, that is the right trade.

Media intake

Uploads are streamed, not buffered whole in memory, and each file is authenticated inside the upload hook before a single byte is written to disk. A file then clears type and size checks, is staged to a temporary location that aborts the moment it exceeds its route’s limit, and only then is persisted to object storage. On the way back out, images are served through signed, resize-on-read URLs rather than exposing the origin object.

Media intake / upload to delivery

Every file is authenticated before a byte is written

Telemetry without a write per view

Usage is measured on a hot path, so it cannot cost a database write per view. Views and events increment counters in Redis and mark the touched entities in a dirty set; a worker flushes on a tick, reads the dirty set, and folds the accumulated counts into the database in one batched transaction.

Telemetry / write path

Views buffer in Redis and flush to Postgres in batches

Two details keep it honest under concurrency. The flush decrements only what it actually wrote, so views that land mid-flush are preserved for the next pass instead of being lost, and an entity leaves the dirty set only once its counter reaches zero. Platform-wide figures (unique visitors and the like) are snapshotted idempotently, so a retried flush can never double-count. A per-visitor lock keeps a single viewer from inflating a counter.

Tradeoffs

The recurring theme is isolation bought with operational surface. A dedicated broker and separate workers keep asynchronous work off the interactive path; a cache-first session keeps identity cheap but adds an invalidation contract to honour; a buffered telemetry path keeps the hot path fast but makes counts eventually consistent. Each of these adds something to run and supervise, and each is deliberate.

Outcome

Reliability & Security

Implemented controls include server-side validation and sanitization, OAuth/OIDC with JWT/JWKS validation, authorization guards, secure cookie configuration, bot verification, selected progressive slow-down, media checks, response projection, queue workers, structured logs, telemetry, cache, and CI gates. These are implemented controls, not a claim of coverage, effectiveness, or certification.

What I would improve

I would take ownership of the identity layer earlier, even though that increases the operational surface area to maintain.

---

Need one technical owner across product architecture and production operations? Discuss your project.