Scala-розробник — функціональні бекенди й дата-пайплайни

Я бекенд-розробник і пишу на Scala, а функціональне програмування для мене — це спосіб мислити про задачу, а не прийом, до якого звертаєшся зрідка. Я проектую сервіси навколо незмінюваних даних, чистих функцій і типізованих ефектів, тому поведінка залишається передбачуваною, а компілятор ловить цілі класи помилок ще до того, як щось потрапить у продакшн. Якщо у вас уже є стек на JVM і потрібні гарантії коректності й конкурентності, які дає Scala, або ви починаєте з нуля й хочете фундамент, який масштабується, а не перетворюється в клубок, — я візьму роботу від архітектури до сервісу, спокійно працюючого в бою.

Більшу частину часу я роблю REST- і gRPC-API, подієві системи й конвейери обробки даних. Будую конкурентні й розподілені бекенди на акторах Akka й Akka Streams, моделюю довгоживучі процеси, що переживають перезапуски, й зв'язую все з Kafka, PostgreSQL, Cassandra або Spark залежно від природи даних. Я думаю про back-pressure й про те, що станеться, коли залежність стане повільною або пропаде, тому мої системи деградують м'яко, а не падають. Пакетні й потокові задачі на великих даних — звична частина роботи: перенесення, очищення й агрегація великих обсягів без втрати записів і без виходу за межі пам'яті.

Одразу позначу рамки: це саме Scala й функціональний підхід, а не звичайна Java, Kotlin або Go, переписані синтаксисом Scala. Я пишу ідіоматичний код з Cats, ZIO або Akka, тестую через ScalaCheck й property-based-підхід й отдаю код, який ваша команда зможе читати й розвивати. Розкажіть про потрібну пропускну здатність і обмеження — пропоную підхід і реалістичний термін.

— Функціональні бекенд-сервіси на Scala (Cats, ZIO)
— Актори Akka й Akka Streams для конкурентних розподілених систем
— REST- і gRPC-API з типізованими тестованими доменами
— Big-data й ETL-конвейери на Spark і Kafka
— PostgreSQL, Cassandra й event-sourced-сховища
— Property-based-тестування й налаштування CI під JVM