Skip to content
AutoCore1.0.0-rc.1 · Release Candidate
1.0.0-rc.1 · Release Candidate2 min read

Application Topology

Understand the responsibilities and boundaries of AutoCore Web, Admin, API, Worker, and infrastructure services.

ComponentResponsibilityMust not do
WebPublic marketplace and buyer/seller presentationOwn server-side business rules or direct database access
AdminAuthenticated marketplace, catalog, legal, payment, and system operationsBypass API authorization or expose secrets
APIValidation, authorization, domain services, persistence, and versioned contractsDelegate authority to client state or search projections
WorkerQueue-backed media, indexing, notification, email, and scheduled work where enabledBecome an unobserved second source of truth
PostgreSQLDurable relational state through PrismaBe replaced by a derived index
RedisQueue, cache, and short-lived coordination roles proven by each moduleBe documented as every possible queue/cache/session role without evidence
MeilisearchQuery, filter, sort, and facet projectionBe treated as authoritative listing state
Media storageBinary objects behind a provider abstractionExpose raw storage paths or provider credentials

Topology flow

  1. A client sends a versioned API request through the public routing boundary.
  2. The API validates input and authenticated scope.
  3. Domain services read or write PostgreSQL and emit audit or side-effect work.
  4. An enabled Worker path processes asynchronous work and updates derived state.
  5. The client receives a stable contract; it does not learn provider secrets or internal network identifiers.

The future mobile application is an API client, not a separate business-logic implementation. Native mobile completion is not claimed by this documentation.

Related articles