Retail commerce platform. Byte4Bit. Federated GraphQL over serverless domain services.
Kasymir
A retail commerce platform built as a federated GraphQL gateway over independent domain services: catalogue, customers, accounting, discounts, imports, analytics and point of sale.
The problem
A retail platform is many products wearing one login: point of sale, catalogue, customers, accounting, discounts, goals, imports and analytics. Each one has its own release rhythm and its own idea of what a busy hour looks like, and every client surface wants a different slice of all of them.
The answer was one federated GraphQL gateway in front of domain services that deploy independently. The clients ask a single schema; behind it, each domain owns its data and its failure mode.
One schema, many owners
Federation lets each domain publish its own part of the graph, so a change to discounts does not mean editing a gateway that everyone shares.
Domains fail on their own
An incident in imports or analytics does not take the till offline, because the services that matter at the counter do not depend on the ones that matter at month end.
Several surfaces, one contract
Point of sale, backoffice and checkout are separate applications reading the same schema, so the data can never disagree between them.
Decisions and the price I paid for them
Federate the graph instead of centralising it
A single hand-written gateway becomes the bottleneck every team queues behind. Federation moves schema ownership to the team that owns the data.
Trade-off accepted
Composition errors are now a deploy-time concern, and a badly modelled entity key is felt across the whole graph rather than in one service.
Serverless per domain
Retail load is spiky and uneven across domains. Paying per invocation per service beats provisioning every domain for the worst hour of the busiest one.
Trade-off accepted
Cold starts have to be designed around on the paths a cashier is waiting on.