Please keep in mind that this is an v3.alpha.2025-06-07 layout version and issues may occur

Ivan Kulagin photo Ivan Kulagin
Hire me

Ivan Kulagin

My name is Ivan, and I am a backend developer since 2012. Since then I selected the stack of different lovely technologies I use daily in my work: Ruby language, TypeScript/Javascript, testing, refactoring, microservices, devops, data parsing/manipulation, APIs design, and of course trendy AI & Automation workflow building (which is actually no/less-code backend development).

Expertise Download CV

spINFLUENCEit

Long-term API project, where I was a head developer of backend side of two applications:

  • one DJ’s desktop app which DJ use to notify the crowd the track he’s playing, respond to music requests, upload his music collection metadata people able to search in, etc.
  • and the second app is a mobile app for party guests, where people can order, vote, like the currently playing track, send tips to DJ, search the DJ’s music collection etc.

Initially the app were built on Ruby on Rails, but soon we decided to replace it with Grape, just because we were not need Rails beast for API, that migration increased performance a lot. As a free bonus we’ve got a swagger docs for API for free. Hanami (formerly Lotusrb) wasn’t mature enough yet, but today I’d definitely use it instead (or even clean Rack app), additionally replacing ActiveRecord which I consider as an antipattern for everything but MVP.

Interesting design decisions/stack used:

  • Firebase for authentication
  • Google Cloud Messaging to interact with guest’s mobile application (broadcasts, direct messages)
  • heavy use of bz2 streams to transfer huge DJ’s music collection metadata
  • stream compressed metadata in NDJSON format
  • PG per-DJ partitioning (at those times there wasn’t native PG solution for that out of the box)
  • multiple external musical APIs integration (cover images look up, search song my fingerprint etc). At some point each background track normalization process called 5 different external APIs
  • of course most core features where covered by tests (unit/feature al kind of, depending on what was the goal of tests)
  • custom Firebase authentication warden strategies implemented for both roles: DJ and Guest
  • few PG triggers implemented on PL/pgSQL to ease work with millions of music tracks data records
  • Braintree payments integration
  • using Que for background tasks (client want no additional elements like Redis in stack)
  • simple S3 integration

This was a very interesting experience, where I had to use all my knowledge about performance optimization and big project (with lots of data) leading development

Visit