Konstantin Shpinev

The goal was to fix recurring Squid connection errors under heavy load, as users often reported that some websites wouldn’t load.

After analyzing network traffic and correlating it with error logs, I noticed that a large number of failed connections were also negatively affecting previously successful ones. This was the key analytical insight that led to identifying the root causes.

Three main issues were found:

First, under heavy load, a race condition in Squid’s code occasionally caused requests to bypass the cache. This was mitigated with a workaround by tuning specific configuration parameters to avoid triggering the bug.

Second, some resolved domains were not being cached due to how the caching mechanism worked internally. This became clear after reviewing the source code and was fixed by reconfiguring those specific domains.

Finally, to increase cache size and lifetime under high load, a configuration parameter needed to be adjusted in the opposite direction from what the official Squid documentation suggested. This was discovered through reviewing the source code and helped eliminate a long-standing misconfiguration.

I was responsible for reworking and migrating a legacy infrastructure that had been running on a single physical server. The process was carried out step by step with minimal downtime, moving all components — including databases, search index, file storage, frontend, backend, and supporting microservices — into isolated environments across separate cloud instances.

To improve reliability and performance, I implemented load balancing and horizontal scaling through multiple application servers. Prior to the migration, users were regularly experiencing service unavailability.

All server configurations were provisioned using Ansible for consistency and reproducibility. I also applied hardening measures to improve overall security.

The deployment process for custom applications was modernized with Docker-based containerization and full CI/CD pipelines. Monitoring and alerting were configured to detect and report critical errors or outages.

As a system architect and developer, I helped design and implement a solution for ingesting and processing large volumes of heavy, heterogeneous datasets. The pipeline includes several stages: parsing, analysis, automatic data annotation, normalization and error correction with analyst involvement, ontology mapping, and indexing for fast, unified search across all datasets.

I was also responsible for deploying the entire system’s infrastructure in Google Cloud. It included an Elasticsearch cluster, multiple databases, application servers, message queues, S3-compatible storage, monitoring tools, and other components.

Microimpuls Smarty is a full-featured IPTV/OTT platform. Its key advantages include:

Affordability. Thanks to the use of mainstream technologies (Python/Django), extensive performance optimization, and real-world stress testing on our own commercial service, Smarty delivers a highly competitive price point — making it accessible even to small providers.

Performance. While competitor solutions often require a large server footprint, we achieved performance levels allowing up to 100,000 subscribers to be served from a single modern server (as of 2018). This was made possible through custom Django caching libraries, C-based modules, optimized scheduling algorithms, regular performance profiling, and system-wide optimization — including a lightweight custom serializer/deserializer and an efficient, low-traffic API. All components can run in a horizontally scalable, fault-tolerant cluster setup.

Smart TV UI framework. One of the things I’m particularly proud of is our in-house UI framework, built specifically for Smart TVs and IPTV set-top boxes, including Android-based devices. The code is optimized for older and lower-powered devices, with TV-specific UX patterns in mind (remote-first navigation, screen layout, etc.). Unlike generic JavaScript frameworks, our solution allows fast development of fully custom, high-performance interfaces.

Infinitely UI. This was a separate UX-focused project inspired by deep research into user behavior across streaming platforms. We benchmarked user flow efficiency against services like Netflix and Amazon Prime — and managed to reduce the number of clicks for common actions like switching between content types, content selection, and navigation. More about Infinitly.

Customization. Smarty is deeply modular. Many internal processes are written as replaceable Python modules, allowing high-level customizations tailored to specific operator needs and unique services.

First industry expo – CSTB 2014. This was Microimpuls’ first public appearance on the market. Despite the product still being in its MVP stage, we signed our first contracts with providers. Feedback from the expo helped us better understand user needs and adjust the product roadmap. It also gave us a clearer sense of what kind of company structure we’d need — one that could support rapid development, customization, deployment, and ongoing support.

Winning the Big Digit Award – 2016. This was the first public recognition of our product’s quality and marked a turning point in how larger providers viewed us. To win, we had to invest seriously in marketing and rethink how we presented our product. Although we already had happy clients, we had to make the product’s value clear to those who didn’t know us yet.

First contracts with major clients. For example, Tattelecom, the largest ISP in Tatarstan with over 1 million subscribers, was one of our first truly large-scale clients. Their high technical demands pushed us to significantly improve the product — boosting performance, flexibility, and UX. This led to the creation of the Futuristic UI, designed in partnership with Tattelecom’s team. Tattelecom had been using a legacy platform that was vendor-locked to outdated set-top boxes. The vendor had stopped development, but replacing the system was considered impossible — until we did it. They needed to launch new services (VOD, OTT TV, etc.) and required a modern interface compatible with Smart TVs. Our solution made that possible.

Mucaster was a point-to-point solution for transmitting live video streams between servers over public internet connections, for further restreaming to end users.

At the time, protocols like SRT didn’t yet exist. The only somewhat reliable way to deliver live streams over unstable networks was using UDP with added redundancy. This increased bandwidth usage but still failed to guarantee stable transmission — especially for Full HD streams (4K wasn’t yet common). Consumer streaming protocols like HLS or RTMP weren’t suitable either, as they relied on significant client-side buffering, while this use case required true low-latency live streaming.

I designed a custom MPEG-TS transmission protocol based on TCP, leveraging its built-in guaranteed delivery through handshake and packet acknowledgment. On top of that, I implemented adaptive bitrate control and dynamic buffering. The system analyzed the stream’s original bitrate to calculate delivery timing, which was encoded along with the video packets. On the receiving side, this metadata was decoded and used to reconstruct the stream and dynamically adjust buffer size and playback rate — compensating for any packet recovery time. In simpler terms, the technology introduced invisible, nanosecond-scale delays into the stream to build just enough buffer to maintain smooth delivery — without noticeable impact for the viewer or downstream devices.

The goal was to modernize the legacy telephony system and transition it to IP, which significantly reduced the cost of connecting new subscribers and maintaining the network. This also enabled new business services like virtual call centers.

I developed the IP telephony platform based on the open-source softswitch OpenSER / Kamailio — a low-level, high-performance SIP server written in C/C++. Unlike Asterisk, which includes built-in call center features, Kamailio required extensive custom development to support production-grade services. I built the system core and modules for dynamic call routing, queue distribution, and auto-dialing, as well as integrated the entire solution into the company’s infrastructure.

The system supported telephony for several thousand customers and over ten business call centers. It also powered a number of automated phone lines with voice menus, allowing customers to check their account balance and initiate payments via the self-service portal. Another feature was a callout system that delivered pre-recorded messages to customers. One of the more original services was a dedicated number that read out the weather forecast for Orenburg, based on data from a weather station installed at Orenburg State University.

The goal was to streamline internal workflows and automate customer request processing. Before this system, requests between departments were handled on paper, and even when digitized, they were stored in scattered Excel files on a shared server — making collaboration difficult and limiting the company’s growth.

I developed a custom internal management system using Python/Django, tailored to the telecom focus of the company.

Key features included: tracking of network infrastructure (objects and communication lines); client and contractor database; numbering resource management for the telecom operator; TV channel cataloguing; a ticketing system for internal task management; client request logging; document storage; and automated reporting tools.

The company set out to launch a new interactive TV service — the first of its kind in the city at the time. I was responsible for selecting and integrating a vendor solution, extending its functionality, and building custom tools for both customers and support staff.

This included desktop IPTV apps, a real-time monitoring dashboard for support (a GPU-powered videowall showing multiple channels), and satellite receiver software for decoding and multicasting channels into the IPTV network.

I also developed an alternative time-shift TV system, replacing the vendor’s unstable DVR module with a faster, more reliable one that could handle higher loads and avoid broken recordings.

I developed a local customer forum based on LiveStreet CMS, where users could share content, build communities, discuss news, and play games. The portal was integrated with a local torrent tracker and game servers.

I developed a call queue processing module — a known bottleneck in the Asterisk IP telephony system at the time. The module was written in C for efficient handling of incoming calls and routing them to operators based on custom business logic.

I got it under unusual circumstances — I discovered a vulnerability in their user portal that allowed transferring virtual funds from a test account to an active one, effectively granting months of free internet access. I reported the issue to the provider, and they offered me a job.

Also participated in DEF CON CTF and various other international CTFs at different times.

Rules of Attack-Defense CTF