E-commerce hosting

Checkout is the least forgiving code path in PHP.

It must never lose a write, and a deployment must never take the shop down with it. Shopware, Lunar on Laravel, and WooCommerce all run on PHP because the ecosystem around payments, tax, and shipping is deeper in this language than in the alternatives.

# Peaks are events, not growth

Store traffic answers to campaigns rather than to a trend line. A newsletter goes out, a piece gets shared, or it's the last Friday in November, and the peak is 10 or 20 times the median for a few hours. Scaling the PHP component up for a campaign and back down afterwards is a normal operation — the good part is that the date is known weeks in advance.

# Orders finish after the request does

Payment capture, stock sync, invoice generation, and feeds to an ERP or a marketplace belong in the jobs component rather than in a request handler. Worker jobs drain the queue, cron jobs run the scheduled syncs, and both are restarted after every deployment so they always run the latest code. A store built that way absorbs a burst in the queue and works through it afterwards.

Card data belongs with the payment provider, not on the shop's own host. What the store does keep — addresses, order history, e-mail — lives in MySQL with the backup component behind it.

# Why fortrabbit?

Because a shop cannot afford a host that flinches at a campaign spike or a deploy, and it can afford even less a host that reinvents itself every year. fortrabbit has run PHP and MySQL on AWS since 2012, bootstrapped, with no habit of moving the ground under its customers. Components scale up for the peak and back down after, orders finish in workers instead of in the checkout request, and every restore point holds a matching database and media set. No ops team needed to watch the graphs.