How can we organize the collaboration of more than a hundred developers on a wide range of topics? How could they decide about good practices in the company? Those are some questions that drove trivago to give it a try on a different structure: the guilds.
At trivago we store a subset of our realtime metric data in InfluxDB and we are quite impressed by the load it can handle. Despite all the joy, we had to learn some lessons the hard way. It is pretty easy to overload the database or the web browser by executing queries that return too many datapoints.
While our company and our application were constantly growing, we often ran into some consistency issues between code and design. Because we didn’t have a design/frontend system and development guidelines to follow, our UI became cluttered and unsustainable.
At trivago we rely heavily on the ELK stack for our log processing. We stream our webserver access logs, error logs, performance benchmarks and all kind of diagnostic data into Kafka and process it from there into Elasticsearch using Logstash.
Tackling hard problems is like going on an adventure. Solving a technical challenge feels like finding a hidden treasure. Want to go treasure hunting with us?View all current job openings
When using webpack to build your assets, it’s only a matter of time until you wish for targeted builds. Whether it’s the output of the library you’re working on (CJS, UMD, AMD, Var, etc.), or the specific feature set (IE8 support, no IE8 support).
parallel-webpack can run those builds in parallel.
One of our core values at trivago is fanatic learning. Twice a year, the trivago software developers gather to have a 2 day internal hackathon. This December saw another round of ambitious creativity, relaxed atmosphere, and good food.
The advances and growth of our Selenium based automated testing infrastructure generated an unexpected number of test results to evaluate. We had to rethink our reporting systems. Combining the power of Selenium with Kibana’s graphing and filtering features totally changed our way of working.
Caching data is an essential part in many high-load scenarios. A local 1st-level cache can augment a shared 2nd-level cache like Redis and Memcached to further boost performance. An in-process cache involves no network overhead, so the cache speed is only limited by local resources like CPU, memory transfer speed and locking.