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, ...
<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
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
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
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
a lifetime) when adding to cart 2. Page contains <esi:include href=”/cart” /> 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
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, ...