Commerce and marketplaces
Isolated sellers, peaks held, reliable events.
Every seller is a tenant: quotas, cache and console isolated. Orders and payments leave as events and signed webhooks, and the gateway sheds load rather than falling over during a peak. It is the gateway of our own marketplace.
What Flexway decides, on your infrastructure
Who calls, what Flexway decides, what is called: each route is a use case of your sector. Dashed: what is coming.
Architecture for commerce and marketplaces: sellers, shoppers and partners go through Flexway, on your infrastructure. Flexway sheds load under saturation even before identity, proves each seller's tenant and holds its quota, may consult your decision service, publishes to Kafka under contract, then sends signed webhooks from the broker to payment and logistics providers, in front of the catalogue and orders and Kafka. A refusal from your decision service gives a 403.
- Sellers
- The marketplace's sellers: each is a tenant proven by its identity, with its own quota.
- Shoppers
- The shop's customers: under heavy load, Flexway sheds non-critical requests first.
- Partners
- The partner companies that consume your APIs: identified by a client certificate or an API key, under a quota per tenant.
- Broker events
- A broker whose messages Flexway consumes to deliver them to your partners as signed webhooks.
- Load shedding under saturation
- Beyond the in-flight cap: 503, before routing; under saturation, adaptive shedding refuses non-critical traffic first, before identity.
- Proven tenant, quota per seller
- The tenant comes from the caller's proven identity, never from a free header; each seller has its own quota.
- Decision service
- Flexway asks your decision service under a bounded deadline; if it refuses (deny), the caller gets 403.
- Kafka publishing, by contract
- Flexway publishes on your broker, under an AsyncAPI contract and in a CloudEvents envelope, what it receives over HTTP.
- Signed webhooks
- Flexway delivers your events to your partners as signed, replayable webhooks.
- Catalogue and orders
- Your catalogue and orders: served to each seller within its tenant, protected from load peaks.
- Kafka
- Your Kafka cluster: Flexway publishes on it the events received over HTTP, under contract, in a CloudEvents envelope.
- Payment, logistics
- Your payment and logistics providers, outside your infrastructure: they receive your events as signed webhooks.
- Line: one route
- Interchange: shared decision
- Request
- Event
- Refusal
- Your infrastructure
- Load shedding under saturationbefore identity, never critical
- Proven tenant, quota per sellerthe tenant comes from the identity
- Decision serviceexternal-call; deny: 403
- Kafka publishing, by contractCloudEvents envelope
- Signed webhooksreplayable, to providers
1A seller looks at their orders
What Flexway decidesThe tenant of their identity replaces any tenant header they would send; your service filters on that proven value; a decision service (external-call) may refuse: 403.
What is protectedA seller never passes for another; the console filters by tenant.
2The sales start
What Flexway decidesUnder saturation, adaptive shedding refuses sheddable traffic first (503 overloaded, Retry-After), before identity; critical traffic is never shed.
What is protectedThe shop stays online during the peak.
3An order is placed
What Flexway decidesThe event is published to Kafka under contract; then, from the broker, providers receive a signed, replayable webhook.
What is protectedNo event lost; providers have no access to your internal systems.
Sellers
The marketplace's sellers: each is a tenant proven by its identity, with its own quota.
Routes through here
Shoppers
The shop's customers: under heavy load, Flexway sheds non-critical requests first.
Routes through here
Partners
The partner companies that consume your APIs: identified by a client certificate or an API key, under a quota per tenant.
Routes through here
Broker events
A broker whose messages Flexway consumes to deliver them to your partners as signed webhooks.
Routes through here
Load shedding under saturation
Beyond the in-flight cap: 503, before routing; under saturation, adaptive shedding refuses non-critical traffic first, before identity.
- Decision
- before identity, never critical
- Catalogue features
- Adaptive load shedding under saturation ; Global in-flight cap: an overloaded replica sheds instead of being killed
Routes through here
Proven tenant, quota per seller
The tenant comes from the caller's proven identity, never from a free header; each seller has its own quota.
- Decision
- the tenant comes from the identity
- Catalogue features
- API keys and client mTLS as first-class identities ; Quota per tenant per day and month
Routes through here
Decision service
Flexway asks your decision service under a bounded deadline; if it refuses (deny), the caller gets 403.
- Decision
- external-call; deny: 403
- Catalogue features
- External call: timeout budget and declared failure behaviour ; Tenant isolation in the console: 403, never an empty list
Routes through here
Kafka publishing, by contract
Flexway publishes on your broker, under an AsyncAPI contract and in a CloudEvents envelope, what it receives over HTTP.
- Decision
- CloudEvents envelope
- Catalogue features
- Kafka publishing under contract, CloudEvents envelope
Routes through here
Signed webhooks
Flexway delivers your events to your partners as signed, replayable webhooks.
- Decision
- replayable, to providers
- Catalogue features
- Signed, replayable outgoing webhooks
Routes through here
Catalogue and orders
Your catalogue and orders: served to each seller within its tenant, protected from load peaks.
Routes through here
Kafka
Your Kafka cluster: Flexway publishes on it the events received over HTTP, under contract, in a CloudEvents envelope.
- Catalogue features
- Kafka publishing under contract, CloudEvents envelope
Routes through here
Payment, logistics
Your payment and logistics providers, outside your infrastructure: they receive your events as signed webhooks.
Routes through here
What the sector requires
- Multi-sellerSellers isolated from each other
- Quota per tenant per day and month, cache isolated per tenant and subject, filtered console; the tenant comes from the identity, never from a header sent, and your service filters on that proven value.
- Orders · paymentsEvents that arrive
- Publishing under contract to Kafka, signed and replayable webhooks to payment and logistics partners.
- Sales · launchesPeaks held
- Adaptive load shedding, a circuit breaker per upstream and a cache for public reads: the gateway refuses the excess cleanly rather than falling over.
- PartnersIntegrations taken over, not rewritten
- API keys and certificates for partners; takeover of an existing gateway configuration.
How Flexway answers
Sellers isolated from each other
- Quota per tenant per day and monthDelivered · v0.1.0
- Authenticated cache, isolated per tenant and subjectDelivered · v1.1.0
- Tenant isolation in the console: 403, never an empty listDelivered · v0.1.0
Events that arrive
- Signed, replayable outgoing webhooksDelivered · v1.5.0
- Kafka publishing under contract, CloudEvents envelopeDelivered · v1.5.0
Peaks held
- Adaptive load shedding under saturationDelivered · v0.1.0
- Circuit breaker with half-open stateDelivered · v0.1.0
- Public response cache, per operationDelivered · v1.1.0
Integrations taken over, not rewritten
- API keys and client mTLS as first-class identitiesDelivered · v0.1.0
- Import of an existing gateway's configuration, with a coverage reportDelivered · v1.1.0
State in Flexway's latest published release; a feature is marked delivered only with its release.
What Flexway does not do
- Flexway processes no payment and stores no card data: it protects and traces the calls to your providers.
- Per-end-user budgets are planned for an upcoming release.
Let's talk about your gateway
Flexwiz is a young company: you talk directly with the person who founds it. Tell us what you want to run through Flexway. We talk about your infrastructure and your digital sovereignty requirements.
Online booking is coming soon; until then, an e-mail is enough.