A microservice-ready architecture for production-like test data
Sixpack combines domain-owned generators, orchestration, buffered datasets, and self-service delivery so distributed teams can request business-valid test states without rebuilding setup logic in every environment.
Architecture overview
A platform layer for orchestration and observability around team-owned state creation
The design separates platform concerns from domain concerns: teams own how valid state is created, while Sixpack owns discovery, orchestration, buffering, delivery, and lifecycle management.
How the model works in practice
Inbound generator orchestration and outbound dataset delivery
Generator orchestration
Domain-owned generator orchestration
Each domain contributes generator capabilities or existing automation in the language and tooling that already fits that system. Sixpack receives those capabilities as inputs into one orchestration layer that can discover, combine, and operate them consistently.
That keeps state creation close to the teams that understand the business constraints, ownership boundaries, and integration contracts.
Platform view
Sixpack composes generator capabilities into reusable cross-service scenarios and exposes them through one consistent operating model for teams and pipelines.
State delivery
Self-service dataset delivery
Sixpack delivers prepared datasets through UI and API so teams and pipelines can request the right state from one consistent self-service interface.
Dataset leasing assigns one prepared dataset to one requesting user or pipeline at a time.
Platform view
Platform-controlled allocation, expiration, and reuse keep shared environments safer for parallel work.
Architecture principles
Best-practice foundations for distributed test data delivery
Ownership
Business knowledge stays decentralized
A professional test data architecture should not centralize every rule in one platform team. Sixpack keeps each domain responsible for how valid data is created while still providing a unified consumption layer.
Resilience
Prepared state reduces operational coupling
Buffered datasets and queued generation protect delivery flow from slow or temporarily unstable environments. Teams can keep working even when some integrations are noisy.
Scalability
Parallel usage is designed in, not patched in later
Leasing, isolation, and catalogued scenarios make it practical to run more tests at once without shared-state collisions or fragile sequencing assumptions.
Solution architecture
Component boundaries, integration protocols, and security model
Technical view
One control plane between inbound generators and outbound dataset consumers
The solution architecture is centered on two machine-to-machine integration points: the generator API and the dataset consumer REST API. On top of those interfaces, Sixpack provides a user-facing web application secured separately for human interaction.
This model keeps the platform responsible for orchestration, discovery, allocation, and observability while generator implementations continue to interact with systems under test from within your own infrastructure boundary.
Generator integration endpoint
Generators register on startup as agents and receive predefined tasks such as generation. They connect with environment-specific identity and mTLS credentials while the custom code that talks to systems under test stays in your infrastructure.
Dataset consumer endpoint
Automated tests request and pick prepared datasets through a REST API. Request parameters such as environment, supplier, item, and optional inputs follow the capabilities that generators have currently registered.
User access layer
Users work through the web interface with OpenID Connect authentication. The UI exposes the same dataset ordering model in a more discoverable and operationally friendly form than direct API use.
Platform control plane
Sixpack holds catalogue, orchestration, leasing, and observability in one control plane so generator capabilities and dataset consumption stay aligned across environments.
Security model
Key technical safeguards
The official architecture documentation describes a model oriented around synthetic data, tenant-scoped integration, and explicit protocol choices for each kind of actor.
Trust boundary
Custom generator code and configuration that interact with your systems remain in your infrastructure rather than being pushed into the Sixpack platform.
Transport security
Generator communication uses gRPC with mTLS, while dataset ordering and pickup use REST over standard TLS.
Identity model
Users authenticate with OpenID Connect, generators authenticate within the tenant namespace, and automated tests use service-style API access.
Data protection
The platform is designed around synthetic data and reference-style dataset metadata rather than full production datasets.
Next step
See how this architecture would map to your delivery stack
If you are evaluating options for complex environments, the fastest next step is a concrete walkthrough of your current setup, constraints, and likely rollout path.