Skip to content
Shipdkit

Architecture

Overview

Section titled “Overview”

The service is split into two planes:

Control plane — where flags are defined and managed. The dashboard, CLI, and management API talk here. Postgres is the source of truth.

Data plane — where flags are served. Materialized snapshots are distributed to the edge and streamed to SDKs. Stateless and read-only.

CLI / Dashboard
      |
      v
+-------------+   publish   +-------------+
| Control     | ----------> | Data plane  |
| plane (API) |   events    | (edge)      |
| + Postgres  |             |             |
+-------------+             +------+------+
                                   | stream / poll
                                   v
                              Your app (SDK)
                            local evaluation

Key Properties

Section titled “Key Properties”
  • Local evaluation: SDKs fetch flag rules once and evaluate in-memory. The network is never on the evaluation hot path.
  • Deterministic bucketing: percentage rollouts use a hash of flagKey + userId — sticky assignments with no stored state.
  • Source of truth separation: Postgres owns definitions; edge storage holds only derived, rebuildable snapshots.

Design Decisions

Section titled “Design Decisions”

The reasoning behind major architectural choices is documented as ADRs: