Written by Henri Normak
In our previous posts, we’ve talked about improving performance by streamlining processing and by minimising the overhead in libraries such as node-postgres, this time, let’s dive deeper into how we’ve reduced our database queries (both read as well as writes) to a minimum.
The original concept of DataLoaders, as described in the repository, came from Facebook in 2010:
… A port of the “Loader” API originally developed by @schrockn at Facebook in 2010 as a simplifying force to coalesce the sundry key-value store back-end APIs which existed at the time. At Facebook, “Loader” became one of…
Written by Jaan Oras
Last time we wrote about how we scaled our services 10x over the course of 30 days. In this post, we’ll dive deeper into one of the more interesting technical improvements we achieved — optimising the way dates/timestamps are handled between the database and application layers.
While profiling one of our services, we noticed that postgres date parsing was taking a substantial amount of CPU, well over 20%. Even though this service loads a lot of time series data, it was still quite surprising to see the amount of CPU cycles it spent parsing dates. This…
At Sixfold we provide real-time visibility for supply chains, you can read more on sixfold.com.
This is the first post in a series, where we will dig deeper into how we ensure scalability of our service and the technical challenges involved. Follow us on Medium to get notified when a new post is published.
Before we dive into the details, a bit of background. As part of the Sixfold product, we ingest quite a lot of data from different sources. …
Sixfold is Europe’s leading real-time transportation visibility platform, solving supply chain visibility challenges for the world’s biggest companies.