Architecture
GoStartKit is designed as a modular product catalog, not a single monolithic framework. Each product owns a clear domain, can deploy independently, and is expected to operate under production traffic patterns.
This page explains the platform shape, composition model, and operational defaults teams should plan around.
Platform shape
Design goals
| Goal | What it means in practice |
|---|---|
| Composable domains | Adopt only the modules your product needs |
| Independent deployability | Scale or update one domain without rewriting everything |
| Operational readiness | Config → init → serve is a first-class workflow |
| Horizontal growth | Multi-instance and read/write separation are baseline capabilities |
| Extensibility | Modules are foundations you customize, not black boxes |
Composition model
Most products start with a small set and expand as domain complexity grows:
| Stage | Typical composition |
|---|---|
| MVP identity | Auth |
| Team / B2B SaaS | Auth + Org-CE |
| Content product | Auth + Article-CE + File-CE + Mail-CE |
| Commerce surface | Auth + Product-CE + Order-CE + Mail-CE |
| Full catalog platform | Auth + Org-CE + Product-CE + Order-CE + File-CE + Mail-CE |
These are patterns, not constraints. Boundaries stay explicit so teams can rearrange ownership later.
Service lifecycle
Every GoStartKit product follows a consistent operational path:
- Install platform binary
- Configure database and runtime settings
- Initialize baseline state
- Serve one or more instances
- Scale with multi-instance / multi-DB / R/W split as needed
- Extend with product-specific logic (often via gskctl scaffolding)
Read/write and multi-instance posture
GoStartKit products are built assuming growth:
- Read/write separation for traffic patterns that outgrow a single write path
- Multi-instance deployment for availability and horizontal scale
- Multi-database readiness when domain ownership or isolation requires it
This keeps “we will scale later” from becoming an emergency rewrite.
Where custom code belongs
| Layer | Responsibility |
|---|---|
| GoStartKit modules | Solved foundations (identity, content, files, orgs, catalog, orders, mail) |
| Your domain services | Product-specific rules, workflows, integrations, differentiators |
| Clients | Web, mobile, admin, and partner-facing experiences |
The recommended strategy is simple: reuse stable foundations, customize the business edge.
Security and access boundaries
Auth is the usual identity root. Other modules integrate with identity and permission concepts rather than inventing one-off access models for every feature.
Practical implications:
- Centralize identity decisions in Auth where possible
- Keep module permissions explicit and reviewable
- Treat tokens, roles, and membership as product-critical surfaces
See Auth for the identity foundation.
Delivery recommendations
- Start with the Getting Started path
- Deploy Auth first if the product has users
- Add one CE module that maps to the core journey
- Keep first production settings boring and documented
- Expand module set only when the product proves the next domain is necessary
Related docs
Architecture is not ceremony. In GoStartKit it is the set of boundaries that let teams ship quickly and keep systems operable after launch.