Live data from Hacker News

How Shopify reduced storefront response times with a rewrite

engineering.shopify.com

1–10 of 76 posts

Re: How Shopify reduced storefront response times with a rewrite

#6
post #2

Is the new implementation still Rails?

I'm assuming the details of exactly what the new implementation is have been deliberately withheld for some future post where they talk specifics (especially if it's something exciting like Rust/Elixir/Go). This keeps the focus of this post on the approach to migration, using the old implementation as a reference in order to burn down the list of divergences, etc.

Re: How Shopify reduced storefront response times with a rewrite

#8
post #3
post #2

Is the new implementation still Rails?

That’s also my question after reading this post. When trying to shave off milliseconds by going for a full rewrite, moving away from ruby seems like an obvious decision...at least intuitively..

Their monolith was written in Rails so Ruby alone was not the source of slow performance. In fact the solution was more to do with cloning the database in order to be able to isolate reads and writes so not even a programming language problem at all.

Re: How Shopify reduced storefront response times with a rewrite

#10
The performance related bits:

- Handcrafted SQL.

- Reduce memory usage, e.g. use mutable map.

- Aggressive caching with layers of caches, DB result cache, app level object cache, and HTTP cache. Some DB queries are partitioned and each partitioned result is cached in key-value store.

Post reply on HN