Skip to content

Architecture

This page summarises the externally relevant aspects of the Sell-Po backend architecture. Internal RFC and ADR documents are intentionally not linked from this site — public-facing architecture documentation mirrors only what consumers need to integrate safely.

Modular monolith

Sell-Po is implemented as a modular monolith running on a single FastAPI application. Modular boundaries are enforced by static analysis (import-linter) so that internal refactoring does not surprise external consumers.

The application is partitioned into nine bounded contexts:

  1. Naver — DataLab, shopping search, search-ad keywords
  2. Coupang — cross-marketplace search and enrichment
  3. Alibaba — 1688 supplier discovery
  4. Analysis — margin, market, integrated, detail
  5. AI Agents — orchestrator + six specialised agents
  6. Billing — Toss subscription lifecycle
  7. Inventory — channel mapping and bundling
  8. Analytics — keyword snapshots and PnL aggregation
  9. Platform — shared infrastructure (auth, audit, observability)

Hexagonal context boundaries

Each bounded context exposes a stable Protocol-based interface. Cross-context calls happen through these interfaces (ports) rather than through internal modules. This pattern keeps the externally observable HTTP surface stable even when internal implementations change.

For external API consumers this means:

  • Endpoint paths are stable across internal refactoring waves
  • Response shapes evolve under explicit semver in the OpenAPI document
  • Breaking changes are announced in the Changelog ahead of cutover

Operational rails

Sell-Po deploys to AWS Lightsail (Seoul region) with a Blue / Green container topology behind nginx, fronted by Cloudflare for DNS, TLS, and WAF. Observability is provided by an OpenTelemetry collector with Jaeger tracing and a Grafana dashboard for DORA metrics.

The same Cloudflare account hosts this documentation site at developers.sell-po.co.kr via Cloudflare Pages.

Reliability commitments

  • Health endpoint — /health returns 200 when all critical dependencies are reachable
  • Blue / Green deploys — every deploy is verified via a smoke test on the green container before nginx flip
  • Atomic configuration — runtime configuration changes are gated by feature flags with default-OFF semantics

Roadmap visibility

Sell-Po follows a phased roadmap focused on stable evolution: incremental modular boundary tightening (Phase D), observability rollout (Phase E), documentation and operational automation (Phase F), and capacity scaling waves beyond. External-facing milestones are summarised in Changelog.