Platform architecture · for a technical audience
How the NEXT BASKET platform is built
NEXT BASKET AI is a microservices-based commerce platform that runs on managed Kubernetes with a major cloud provider. This page describes the real architecture, the infrastructure, and the engineering practices behind it — without the marketing layer. The figures below are based on an internal platform verification completed on January 24, 2026, and on operational reports; they may change as the platform evolves.
- automated tests at a 97.8% pass rate · internal verification, January 24, 2026
- 16,175
- backup strategy with independent restore paths across multiple clouds
- Multi-layer
- restore drill — backups verified by a real tenant restore every week
- Weekly
- logically isolated tenant data in the multi-tenant core
- Multi-tenant
The engineering approach, in brief
A platform built as independent services, delivered declaratively, and verified automatically on every change.
Instead of a single monolith, NEXT BASKET is split into independent microservices — each owning one clear commerce domain. A fault in one service does not take down the others; each is deployed, scaled, and updated on its own.
All software is delivered through a GitOps model: the desired state of the system is described in Git and reconciled to the cluster on a human-approved sync. Every change passes a set of automated checks (CI gates), container images are covered by supply-chain controls, and rollback is immediate. The infrastructure itself is managed as code.
High-level architecture
The path of a request — from the shopper to the data — through the platform’s layers.
Clients
- Shoppers · web / mobile browser
- Merchants · back office
Edge · protection
- Cloudflare CDN
- WAF · DDoS protection
- TLS termination · Cloudflare edge
Cloud · ingress
- Managed load balancer · IPv4 + IPv6
- Ingress controller
- Managed Kubernetes · EU region
Application layer
- Storefront · Next.js
- Back office · React
API gateway
- API gateway · routes /api → microservices
Microservices · one per domain
- Identity
- Stores
- Catalog
- Orders
- Payments
- Location
- Notifications
Data layer
- Managed data stores · operated by specialized providers
- Email · transactional
Observability
- Metrics · continuous
- Dashboards · live view
- Alerting · on deviation
Resilience · multi-layer backup
- Multiple independent layers
- Offsite + second cloud
- Verified restores
Delivery & control plane: GitOps with human-controlled sync · infrastructure as code · container registry with supply-chain controls · encrypted secrets management (no secret material is committed to Git in plaintext).
Technology stack
Proven, industry-standard technologies at every layer — nothing exotic that would become a maintenance liability.
Frontend
The public storefront and the back office are separate applications with server-side rendering for speed and SEO.
- Next.js
- React
- SSR
Backend
Microservices in PHP / Symfony, each owning its own data. They communicate through an API gateway.
- PHP 8
- Symfony
- API gateway
- REST
Data
Managed data stores from specialized providers — the platform team does not hand-operate database servers.
- Managed data stores
Orchestration
Services run on Kubernetes with horizontal pod autoscaling on the high-traffic services and pod-level self-healing. Each service deploys independently with zero-downtime rolling updates.
- Managed Kubernetes
- Autoscaling
- Ingress
Delivery · GitOps
Declarative deployments from Git. Supply-chain controls, human-controlled sync, and immediate rollback.
- GitOps
- Infrastructure as code
- CI pipelines
Edge · security
Cloudflare sits in front of all traffic for speed and protection, and terminates TLS at the edge. Secrets are encrypted and applied out-of-band.
- Cloudflare
- WAF
- TLS at edge
- Encrypted secrets
Microservices and their boundaries
Each service owns its own data and is responsible for one clear commerce domain.
Identity & access
domain
Authentication, roles, permissions, and access to stores.
Stores
domain
Stores (tenants), domains, configuration, and data isolation.
Catalog
domain
Products, variants, attributes, inventory, and product feeds.
Orders
domain
Cart, checkout, and the order lifecycle.
Payments
domain
Payment-provider integrations built for safe retries.
Location & shipping
domain
Addresses, regions, carriers, and shipping logic.
Notifications
domain
Email, SMS, and events to the shopper and the merchant.
Background work
async
Heavy work runs asynchronously, kept off the request path.
Isolation: each service owns its own data and communicates through defined APIs. Workloads are network-isolated and can reach only the dependencies they need.
Infrastructure: managed cloud
Production runs entirely on a major cloud provider’s managed Kubernetes.
The production cluster runs in an EU region across multiple nodes behind a managed load balancer (IPv4 + IPv6). Service images live in a container registry under supply-chain controls; data and storage are provider-managed, and backups flow to multiple independent offsite locations.
Compute: Managed Kubernetes — the cloud provider operates the control plane and the nodes; we deploy the services.
Network: A managed load balancer plus an ingress controller behind Cloudflare. Dual-stack IPv4 + IPv6, edge TLS termination, and health checks.
Registry & images: A container registry of scanned images with supply-chain controls. Every deployment points at one exact, immutable image.
Data and multi-tenancy
One cluster serves many stores — with each store’s data logically isolated.
NEXT BASKET is multi-tenant: a single platform hosts hundreds of separate stores. Each tenant has its own configuration and logically isolated data, and our regular restore verification covers tenant data in full. All persistent data lives in managed data stores, with each service owning its own data.
Managed data stores mean the backups, replication, and upgrades of the databases themselves are handled by specialized providers — the platform stands on a dependable foundation instead of reinventing database operations.
Resilience, backups, and recovery
Multiple independent backup layers, tested every week with a real restore — not just on paper.
| Layer | Approach | Frequency | Retention | Location |
|---|---|---|---|---|
| Multiple independent layers | independent backup paths | recurring | defined windows | across the platform |
| Offsite + second cloud | encrypted copies | recurring | defined windows | separate provider · second cloud |
| Verified restores | automated restore drill | weekly | evidence retained | isolated test environment |
- Recovery objectives
- Defined & measured
- for both data loss and restore time
- Restore drills
- Weekly
- verified by a real tenant restore
- Evidence
- On request
- moving to the Technical Evidence Center
Weekly restore drill (tested): backups are verified by a real restore into an isolated environment — confirming they restore cleanly, watched by independent alerts. In the latest documented run, the result was PASS.
Security
Defense is layered — from the edge to the secrets — and verified automatically on every code change.
Edge and traffic
Cloudflare WAF, DDoS protection, and rate limiting in front of all traffic. TLS is terminated at the Cloudflare edge, with encryption to the cluster.
Secrets
No plaintext secrets in Git. Secrets are encrypted before they reach the cluster and decrypted only inside it.
Network isolation
Workloads are network-isolated, and a scoped delivery boundary constrains the blast radius of every deployment.
Supply chain
Automated vulnerability scanning, secret-leak detection in CI, and a guard against compromised base images. Image provenance is controlled from build to deployment.
Payments and data
Payments run through PCI DSS–certified processors. GDPR tooling for consent, export, and deletion of personal data.
On the roadmap
beta: two-factor authentication (2FA) and a public status page · planned: image signing (cosign) and admission policies.
Quality and change delivery
Every change is traceable, automatically verified, and reversible.
Automated tests
Based on an internal platform verification completed on January 24, 2026, the platform runs 16,175 automated tests at a 97.8% overall pass rate — covering backend services, the public storefront, the back office, AI services, and edge cases. These figures may change as the platform evolves.
CI gates
A change does not reach production unless it clears a set of required checks: tests, linters, secret and vulnerability scans, and rendering-stability checks.
Reversibility
GitOps means every deployment is a commit in Git. Rolling back is a rollout undo or a git revert — in seconds, with no manual work on servers.
Observability: an industry-standard monitoring stack watches the services continuously; alerts fire on deviation before customers notice a problem. A separate public Technical Evidence Center is planned, with architecture, test reports, security status, and recovery evidence.
This page describes the technical architecture of the NEXT BASKET AI platform as of publication. The availability of specific features may depend on the selected plan, region, and contract. Figures are based on an internal platform verification completed on January 24, 2026, and on operational reports; they may change as the platform evolves.
- Managed Kubernetes · EU region
- Multi-tenant · logical isolation
- Multi-layer backup · tested weekly
- GitOps · reviewable deployments