Skip to main content

Architecture Deep Dive

Purpose​

This page explains Cyprob EE architecture boundaries and runtime flow for technical evaluators.

Validity Note​

  • Status: CONFIRMED
  • Basis: Architecture and behavior claims are validated internally against current implementation and deployment runbooks.

Layering Model​

Cyprob EE follows strict DDD layering:

  • Transport: HTTP handlers, DTO parsing, route security metadata
  • Application: orchestration, transactions, workflow decisions
  • Domain: business rules, entities, invariants
  • Infrastructure: PostgreSQL, external systems, persistence

Runtime Topology​

Core runtime components:

  • API/control plane
  • Worker execution plane
  • PostgreSQL state store
  • Optional runtime services (watchers, reverse proxy, secret backends)

Orchestration Pattern​

The scan orchestration model is queue-driven and phase-based:

  1. Scan requested
  2. Jobs enqueued per phase/chunk
  3. Workers execute and publish progress/results
  4. Phase completion advances orchestration

Reliability Controls​

  • Idempotency guards for phase advancement and job generation
  • Heartbeat-based worker liveness tracking
  • Retry/reassignment behavior for failed worker execution
  • System-state gates (operational/read-only/setup-needed)

Security-Relevant Boundaries​

  • Org-scoped API boundaries enforced in route/middleware model
  • Permission-scoped endpoints (resource:action)
  • Secret retrieval separated from application business logic

Next Action​

Continue with Scanning Lifecycle.