Challenges at Kiwi.com: Connecting hundreds

Tin Markovič (Booking Backend team leader at Kiwi.com) @ Brno-Moscow Python Meetup 2

"What is Kiwi.com? Why is engineering so important to a travel agency? How do we solve our problems? Tin will answer these questions and more when he explains the methodology of this budding techno-travel giant. We'll look at the problems of growing at breakneck speed, the advantages of being in a friendly environment and the challenges that make it all exciting".

Video: http://www.moscowpython.ru/meetup/2/kiwi-challenges/

Transcript

1. Tin Marković, Senior Software Eng Challenges at Kiwi.com Connecting hundreds
2. 2 Introduction and Overview  How does Kiwi.com work  Who are we? Why are we here?  What are our daily problems  Our daily challenges  Assets and the work we do
3. 3 Speaker  Tin  Team Leader at Kiwi.com  Software Architecture as passion  Experiences working big projects (edX, Texas U, Kiwi)  Where do I fit in the Kiwi picture?
4. 4 Company: Kiwi.com  Making travel better  Our vision is to make travelling simple and accessible to everyone
5. 5 Kiwi.com and Python  We develop using mainly Python  Startup beginnings (and present)  Adaptability and quick scaling  Try. Fail. Learn.  EAFP
6. 6 The Problems  Our scale is enormous with worldwide scope  We need better standards  Our environment changes often  Growing pains of a huge company
7. 7 The Problems II  Python lets us move rapidly, but...  Issues:  Type security  Dictionaries: mutable, dynamic, nested  There's more than one way to do it
8. 8 The Challenges  Speed of delivery  Changes have to come weekly and daily  Downtime is unacceptable  Dozens of bookings a minute  Making travel better  Customer experience: reliable and verbose
9. 9 The Assets  Great Tooling  Continuous Integration & Source Control  Process, but measured  Code review, trainings and education budget  Safety nets  Blameless, failures are expected
10. 10 The Assets II  Static:  PyLint, mypy, Coala, SonarQube  Logging:  Sentry, Pagerduty, Datadog, Kibana logs  More? → Refactoring in Python (PyConf Moscow)
11. 11 The Work  What do I do?  The Bag Man, Mambo  Precise, when it can be  A lot of obscurity and vague rules  Visible impacts  Conversion rate, consumer satisfaction
12. 12 The Work II  Booking → Monolith  Scrape off part by part — services separated  From: Method/Function oriented approach  To: Resource/Item oriented approach (OOP!)  REST-ish → Swagger/OpenAPI + Connexion  Doing it right, but mindful of business needs
13. 13 The Work III  Demanding:  Mapping the processes  Edge cases and their validity  History of code  Issues with service split:  Edge cases get reimplemented  Hereditary implementation - undocumented
14. 14 The Work IV  Splitting services - summation:  Mapped processes invalidate edge cases  System can be forced into a stronger model  Operation based API doesnt scale: focus on resources  Stricter validation with Python: scheme everything  Use modules generously: encapsulate everything shared and share business logic through all services
15. ANY QUESTIONS? You can find me at tin.markovic@kiwi.com Thanks!