At Allegro we use Solr as our main search engine. Due to the traffic to our search engine being thousands of requests per second and index size on the order of a hundred million documents we need to develop custom optimizations. In this post I will describe the story of our Solr plugin development.
We messed up. On July 18th, 2018, at noon, Allegro went down and was unavailable for twenty minutes. The direct cause was a special offer in which one hundred Honor 7C phones whose regular price is around PLN 850 (about € 200), were offered at a price of PLN 1 (less than € 1). This attracted more traffic than we anticipated and at the same time triggered a configuration error in the way services are scaled out. This caused the site to go down despite there being plenty of CPUs, RAM, and network capacity available in our data centers.
So you have created a brand new and shiny Node.js based app. And now, how would you like it deployed? How to pack it and deliver to a production environment? In this post we’ll describe this process (we assume some familiarity with the concepts of Node.js and npm).
Even though a lot of software development is high-level stuff which does not require the developer to delve into the details of how things work under the hood, in certain situations it can be very helpful to know what sort of low-level operations an application is performing. Two typical scenarios are performance tuning and debugging.
This post is about migrating a real-world, non-trivial, business-critical application from Java 7 to Java 8. When searching for a JDK 8 migration guide, you can often find blog posts that claim to be helpful but in reality only repeat the list of features found in release notes and offer no insight into issues you may encounter in practice. Having no migration guide during our own migration, we decided to create one. This is a report right from the trenches, no details spared, casualties included.
