Skip to content

Going remote

FlyokaiMarketplaceRemote (flyokai/sw-marketplace-remote) offloads marketplace work from Shopware's PHP-FPM workers to a separate Flyokai async cluster. It requires Base and changes only one thing: how a request is dispatched.

When to install

Install Remote when you hit Base's in-process ceiling:

  • Marketplace API traffic competes with shop traffic for the same PHP-FPM worker pool and you can't scale Shopware fast enough.
  • Heavy marketplace writes (statement generation, payout runs, big mailings, bulk imports) contend with storefront InnoDB locks.
  • You want to scale marketplace compute independently of Shopware.

If none of these bite, stay on Base — it's a strictly simpler deployment.

What changes (and what doesn't)

Base only Base + Remote
MarketplaceBackend binding LocalMarketplaceBackend (in-process) RemoteMarketplaceBackend (→ cluster)
/flyok-portal/* routes Shopware (Symfony) Shopware — unchanged
OAuth token issuance Shopware Shopware — unchanged
Admin Vue, cart, storefront, mail Shopware Shopware — unchanged
Where marketplace data lives Shopware MySQL Shopware or cluster MySQL — see below

The install is the switch. Remote's build() registers a CompilerPass that unconditionally rebinds the MarketplaceBackend alias to RemoteMarketplaceBackend. There is no FLYOKAI_MARKETPLACE_MODE env var.

Two data-location modes

Where the data plane lives is a separate decision from installing Remote, controlled by dataLocation — but never edit that dropdown directly. Flip it only through the migration commands so data moves atomically.

dataLocation=shopware (default after install)

Shopware (Base)                           Flyokai cluster
  ├─ /flyok-portal/* → Symfony              ├─ channel :1439
  ├─ OAuth → Symfony                        ├─ HTTP    :1339
  ├─ marketplace data tables  ◄── reads ────┤ workers
  └─ flyokai_user, OAuth tables             └─ cluster infra on cluster MySQL

The cluster connects to Shopware's MySQL for the data plane. Pure compute offload — no migration, no data movement. Best when PHP-FPM is the bottleneck but MySQL has headroom.

dataLocation=cluster (after explicit migrate)

Shopware (Base)                           Flyokai cluster
  ├─ /flyok-portal/* → Symfony ─────────────► channel :1439 → workers
  ├─ OAuth → Symfony                        ├─ marketplace data tables
  └─ flyokai_user, OAuth tables             └─ cluster infra (both on cluster MySQL)

The cluster uses its own MySQL for the data plane; Shopware retains only the identity plane. Reached via an explicit marketplace:data:migrate:to-cluster. Best when MySQL contention with shop traffic is the bottleneck.

Identity never moves

flyokai_user, the OAuth tables and the mail outbox always stay Shopware-side. The cluster's own bootstrap tables (flyok_user, flyok_oauth_*, …) stay pinned to the cluster's MySQL via a separate infra connection pool. So flipping dataLocation never disturbs either side's auth — JWTs issued by Base remain valid throughout.

Install & bootstrap

composer require flyokai/sw-marketplace-remote
php bin/console plugin:refresh
php bin/console plugin:install --activate FlyokaiMarketplaceRemote

Then configure under Settings → Plugins → FlyokaiMarketplaceRemote (or via marketplace:remote:bootstrap):

  1. Marketplace data location — leave at shopware initially.
  2. Cluster flyok.config.json path — the file the migration commands rewrite to flip db.connection.active.
  3. Cluster restart command — default sudo systemctl restart flyokai-cluster (needs a passwordless sudoers rule, or swap for your process manager).
  4. Shopware MySQL coordinates — how the cluster reaches Shopware's MySQL when dataLocation=shopware.
  5. Flyokai cluster connection — host, channel port (1439), HTTP port (1339), TLS flags, and OAuth client_id / client_secret (issued on the cluster via flyok-console oauth:client:create).

Seed the cluster's connection blocks once:

php bin/console marketplace:remote:cluster-config:init

This idempotently writes db.connection.shopware + db.connection.cluster into the cluster's flyok.config.json, normalises a legacy active=default to active=cluster, and syncs Shopware's dataLocation with the cluster's active selector. Supports --dry-run, --force, --active=shopware|cluster.

Verify:

php bin/console marketplace:ping
# Backend: Flyokai\MarketplaceRemote\Service\RemoteMarketplaceBackend
# OK: N seller(s) total, ...

Operational notes

  • Pool sizing under dataLocation=shopware. Cluster workers and PHP-FPM workers both draw on Shopware MySQL's max_connections. Keep db.connection.shopware.max_connections conservative per worker, or raise mysqld's max_connections to match.
  • No silent fallback. If the cluster is down, sendRequest() returns null and the portal shows errors — deliberately. Under dataLocation=cluster, a silent in-process fallback would read the wrong database.
  • Stale workers after restart. If the restart command reports success but marketplace:ping still fails, check ss -lntp for stale processes holding ports 1339 / 1439.
  • OAuth keypair stays in Shopware's var/marketplace/; the cluster verifies portal JWTs with the public key only.

Next

Ready to move the data plane onto cluster MySQL? See Data migration for the safe, resumable migrate procedure.