Put your seat back and relax as Kiwi.com's Martin Strycek describes how this European travel booking giant was able to get above the clouds and make travel better with Scylla. Learn their topology, dataset, sizing, and how they continued scaling using Scylla's new SSTable format and the "bypass cache" command.

1. Kiwi.com Reaches Cruising
Altitude with Scylla
Martin Strycek, Engineering Manager

2. Presenter
Martin Strycek, Head of Infrastructure
I’m passionate about my work. I love helping companies grow
by constant innovation in technologies.
I was employee number 3 of piano.io a world leader for online
content monetisation.
Steered technology growth at Exponea Fastest Growing SaaS in
Europe.
2 years at Kiwi.com and I’m loving it!

3. Kiwi.com

4. Kiwi.com
The travel tech company was created for travellers by travellers.
We're on a mission of making travel better by building a virtual global
supercarrier.
■ Founded in 2012 as Skypicker
■ In 2014 Big boom and first Customer center
■ In 2019 Partnering with General Atlantic
■ A day in Kiwi.com
● 100 000 000 Average daily search queries
● 35 000 Average seats sold per day

5. Kiwi.com

6. ScyllaDB @ Kiwi.com

7. How we use Scylla
■ We store all the raw data in Scylla
● Flights
● Trains
● Busses
■ Dataset
● exchange 60% of data every day,
● 80% data every 3 days, 100% every 10 days

8. Topology
■ Dedicated connect to cloud
■ 3 DC
■ Bare metal

9. Topology

10. How we booked the flight
with Scylla

11. Proof of Concept
■ March 2018
■ Tested on Bare metal, GCP
■ Redesigned infrastructure
■ Looking into Full table scans + big reads + big writes

12. Scylla Summit 2018 - 21 servers cluster

13. Python to Golang
“What We Have Learned Running ScyllaDB and Go”
by Martin Sucha

14. The sizing

15. The sizing
Estimation Final Prod

16. Cabin crew clear for take off

17. Topology
■ Dedicated connect to cloud
■ 3 DC - each DC is 1 copy of data
■ Bare metal

18. Numbers
■ 400 000 reads/second
■ 600 000 writes/second
■ 0 - repairs completed from production lunch
● exchange 60% of data every day,
● 80% data every 3 days, 100% every 10 days

19. How we use it

20. Seatbelt sign is OFF

21. ONE vs LOCAL_ONE
■ Not replica in a DC
■ Cross DC traffic

22. Cache misses
■ 90M of rows
■ Imbalancing the response ms

23. Dinner and drinks
being served

24. 2019.1
We had high expectation from this version
■ Bypass cache
■ Workload prioritisation
■ MC

25. 2019.1 features placement

26. Bypass cache

27. Workload prioritisation
Sorry Glauber we don’t need it right now
■ Slightly oversized cluster
■ To keep responses as fast as possible
■ Bypass cache improvement
● from 520 seconds to 330 seconds ~ 35% improvement

28. The MC

29. Upgrade 2019.1

30. Upgrade 2019.1
1h 56m

31. Upgrade 2019.1
7h 18m since upgrade started, while eating breakfast

32. Thank you for a boring
database

33. martin.strycek@kiwi.com
martin.strycek@gmail.com
Martin Strycek
@martin_strycek
Stay in touch