A tech conference is a gathering of tech enthusiasts, geeks, and wizards who come together to share their magic spells (aka tech knowledge), cast some illusions (aka demos), and talk about the future of technology in a professional yet humorous way. It's a place where you can explore the latest tech trends, make new connections, and have a great time with like-minded individuals. So, pack your wizard hat and prepare to be inspired by our tech conference called trivago Tech GetTogether (TGT)!
As a part of the series of posts already mentioned on WARP - A Web Application Rewrite Project, we are disclosing our process of making technical decisions. We hope that you find this process helpful. Maybe you can even pull something out for your own projects.
One of the many responsibilities of a Site Reliability Engineer (SRE), is to ensure uptime, availability and in some cases, consistency of the product. In this context, the product refers to the website, APIs, microservices, and servers. This responsibility of keeping the product up and running becomes particularly interesting if the product is used around the world 24 hours every day like trivago. And just like in the medical profession, someone has to be on call to react on failures and outages outside of the office hours.
Scalability and availability are key aspects of cloud native computing. If your microservice takes five minutes to start up, it becomes very difficult to meet the expectations because adjustments to traffic changes, regional failovers, hot-fixes and rollbacks are simply too slow. In this article, we show how we solved this and a few other problems by taking control of the process of updating our data and storing it in a highly available Redis setup.
At trivago we operate on petabytes of data. In live-traffic applications that are related to the bidding business cases we use our in-house in-memory key-value storage-service written in Java to keep data as close to calculation logic as possible.
Have you ever wondered about how to create components that not only change their appearance according to the viewport’s width but instead also transform according to their parent element’s sizing? This might be the case when you have a card component that has the classical vertical layout on mobile: