# Why we decided on Kotlin in our Data Engineering architecture

DevFeed: [Why we decided on Kotlin in our Data Engineering architecture](<https://devfeed.tech/articles/why-we-decided-on-kotlin-in-our-data-engineering-architecture-24748.md>)

Original publisher: [Read original article](<https://medium.com/yazio-engineering/why-we-decided-on-kotlin-in-our-data-engineering-architecture-36adddb349cc?source=rss----65bd178b00af---4>)

Author: Dominik Liebler

Published: 2023-03-13T10:27:51Z

Content type: opinion

Language: en

Sources: [YAZIO Engineering - Medium](<https://devfeed.tech/sources/yazio-engineering-medium.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [data-engineering](<https://devfeed.tech/topics/data-engineering.md>), [Kotlin Multiplatform](<https://devfeed.tech/topics/kotlin-multiplatform.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Back end](<https://devfeed.tech/topics/backend.md>), [Python](<https://devfeed.tech/topics/python.md>)

Tags: [analytics](<https://devfeed.tech/tags/analytics.md>), [data-engineering](<https://devfeed.tech/tags/data-engineering.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [legacy](<https://devfeed.tech/tags/legacy.md>), [maintenance](<https://devfeed.tech/tags/maintenance.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [python](<https://devfeed.tech/tags/python.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>)

## AI overview

The article explains why YAZIO chose Kotlin for its data engineering architecture. It describes dissatisfaction with Python's runtime type checking and recurring basic bugs, then outlines Kotlin's stability, consistency, JVM library ecosystem, Kotlin Multiplatform code sharing, backend experience, and opportunities for knowledge sharing with mobile developers.

## Source excerpt

Choosing or changing a software architecture is not an easy task -- it requires careful consideration of many factors. The decision can have long-lasting effects on the development process, maintenance, and scalability of the system but also on developer happiness and employer churn rate -- nobody likes working with bad legacy code or fixing architectures not scaling well to the needs of an organisation. Photo by 30daysreplay on Unsplash Turn back time to 2021 and you'd see some basic Kotlin code, a pile of Python, and some SQL as well as a lot of YAML for Kubernetes resources in our tech stack. At this point in time the team already had a lot of experience in building software in general and data systems like ETLs in particular but we weren't very happy about the current process and most of all with Python. Although it allowed us to quickly ingest new data from HTTP APIs, we often experienced bugs in our software that were very basic: an AttributeError here, an edge case resulting in a KeyError there -- typical things that can be prevented at compile time in another language. What about a typed language then? We tried annotating our code with type hints using the typing package, but they weren't enforced by the interpreter at runtime anyway and can only really be helpful if PyPi packages also provide typings. Photo by Samuel Schroth on Unsplash As mentioned earlier we already had some Kotlin code running in production due to the fact that we share code with our mobile clients for iOS as well as Android (using Kotlin Multiplatform) and we were very pleased with it. Also as most of the team already had prior experience running Kotlin backend services in production, we decided to go all-in on Kotlin (where possible™). These are the reasons why we think it's a good idea to this day: stability and consistency ability to use the vast amount of libraries for the JVM being able to share code (for event tracking) using Kotlin Multiplatform previous positive experience running