OPTIONS FOR SCALING OUT 1.Add hardware & caching • and deal with “great” code • Recurring license costs... • ... per server, usually! • Rinse and repeat for the next shop you launch 2.Build it yourself • Investment up front • Needs maintenance • Hybrid approach makes a lot of sense: keep old software for cart, checkout, payment, ...
OUR GOALS • Home page, product detail, category browser, search: <100 ms • Try to degrade, but not to fail, under extreme load • Prefer failures for some users over slowness for all users • Sacrifice freshness of data and features for performance • Replicate any change in product DB to front-end in <60 s
FOR THAT, WE NEED: • A share-nothing architecture (or at least a “share little” one) • Failover configurations where needed (load balancer, cache, ...) • An FTS capable database that withstands a lot of parallel reads • Ideally, an approach where we don’t even hit an app server
TRADITIONAL HOSTING OR THE CLOUD? A) Host everything yourself B) Only use SaaS and components like S3, CDNs and so forth C) Host some parts yourself, and others on AWS or similar D) Host everything in the cloud
SPECIAL MENTIONS • Bundle Inheritance • Base implementations for Search, Product, Category, ... • Sites (Kiveda, ...) may override templates, controllers, ... • Twig • Share templates (at least some) between “Fox” and OXID
REPLICATING MYSQL TO ES • Triggers on product/category/... tables write to a table with commands for replication • Script (Symfony CLI) runs periodically, reads replication commands and replays them into ElasticSearch • supervisord keeps it alive (crons could overtake each other) • Sends PURGE commands to Varnish
LOGINS & SHOPPING CARTS A) ESI: Set cookie when adding to cart, detect cookie in VCL B) XHR: No server-side work, but latency on the client side, and you need to deal with CORS even for just HTTP vs HTTPS C) Signed cookies
ESI TRICK FOR THE CART 1. Set marker cookie (with a lifetime) when adding to cart 2. Page contains 3. If cookie above exists, hit backend 4. If not, rewrite location to “/cart_empty.html” in vcl_fetch 5. Same can be done for logged in users
ADDED BENEFIT: DEV ENVS! • Build a Veewee base box that mirrors production config • Use Vagrant and Puppet manifests from production for dev! • Quickly test e.g. a new ElasticSearch node going up or down • For the future: • Run staging using https://github.com/fgrehm/vagrant-lxc • Devs can log in and kill the database, add web nodes, ...