Application Surfaces
See how AutoCore Web, Admin, API, Worker, data stores, search, and reverse proxy fit together.
AutoCore is composed of separate application surfaces that use the same versioned API boundary. The clients present workflows; the API owns business logic; the Worker handles asynchronous work; infrastructure services provide durable state, coordination, and search.
Surface responsibilities
| Surface | Boundary |
|---|---|
| Web | Public marketplace pages and buyer/seller-facing interactions. It should not become a second business-logic layer. |
| Admin | Authenticated operations for users, roles, catalog, listings, media, legal, consent, payments, and system visibility. |
| API | NestJS application boundary for validation, authorization, domain services, persistence, and versioned HTTP contracts. |
| Worker | Background processing through Redis-backed queues, including search indexing, media, notification, and scheduled jobs where implemented. |
| PostgreSQL | Prisma-backed relational source of truth for users, installation state, markets, catalog, listings, policies, consent, and related records. |
| Redis | Queue, cache, and short-lived coordination service. It is not the durable source of marketplace records. |
| Meilisearch | Search projection used for query, filtering, sorting, and faceting. It can be rebuilt from durable data when the supported reindex path is used. |
| Reverse proxy | External routing and TLS boundary that maps public hostnames to the Web, Admin, and API services. |
Request and background flow
Browser or future mobile client
|
v
Reverse proxy / TLS
| |
v v
Web Admin
\ /
\ /
v v
Versioned API
| | |
v v v
PostgreSQL Redis Meilisearch
|
v
Worker
The text diagram above is intentionally the accessible alternative for this phase. The current docs platform renders fenced code blocks but does not yet render Mermaid diagrams. A future diagram integration should preserve these same boundaries and add equivalent text, keyboard, and screen-reader descriptions.
Figure: Anonymous public demo capture from autocoredemo.mcorucu.com, reviewed
for synthetic fixture content and optimized as WebP. Text alternative: the Web
surface presents public marketplace discovery and search; authenticated Admin
and future mobile clients remain separate API consumers.
Source-verified qualification
The architecture describes the intended API-first topology. Current source also distinguishes registered queue names from enabled worker consumption: some scheduled or rollout-gated processing remains disabled until its flags and operational prerequisites are approved. Documentation therefore uses “designed,” “registered,” or “enabled” precisely instead of treating every future-capable queue as active by default.
API-first consequence
Web, Admin, and a future mobile application are clients of the API. A client can format and compose a view, but it must not bypass API authorization or duplicate business rules. Shared contracts, types, constants, i18n, and design tokens exist to support reuse without importing one application into another.
Operational consequence
An interactive request can be healthy while a Worker, search projection, media provider, or reverse-proxy route is unhealthy. Service health checks therefore need to cover the application and its dependencies together. Later Operations pages will define the detailed checks and recovery procedures.
Security boundaries
- The API and Admin enforce authentication and authorization for protected operations.
- The public installation status endpoint is intentionally limited to safe status data.
- Secret values, provider credentials, and server-only edition configuration must not be sent to browser clients.
- The reverse proxy is an exposure boundary, not a replacement for application authorization.