Sergey Vareyko / Distributed Systems

Distributed systems architecture: high-load Java, event-driven services and performance

Distributed systems architecture decides whether a platform that works today still works when its load multiplies, and what it costs to run when it does. The work is in the parts that do not show in a demo: services that scale out instead of up, queues that absorb bursts, search indexes and caches that keep reads cheap, and operations that keep the whole thing running around the clock. This page is for companies whose Java platform is approaching its limits, and for teams designing one that must not hit them. I have done this work as an architect and as an engineer on platforms for digital signage, music generation, logistics, cybersecurity and payments.

Proven results

  • Over 10,000 screens on the same infrastructure. On Vrtly, where I was the software architect and team lead, the platform grew from approximately 1,600 to over 10,000 concurrently managed screens without increasing the infrastructure footprint.

  • An architecture for 100,000. I designed and evolved Vrtly's horizontally scalable microservices architecture to support growth beyond 100,000 connected screens without a fundamental redesign, and established reliable 24/7 production operations.

  • Rendering spread across workers. On Soundful I designed a distributed audio processing architecture with asynchronous task queues, specialized rendering workers and containerized execution, and a multi-level audio cache that reduces redundant processing.

  • Cheaper storage and compute at volume. On Turvo I optimized Elasticsearch storage for large volumes of logistics data, optimized CPU-intensive operations on large datasets and reduced AWS expenses.

  • Event streams as a shared service. For Altir Foundation I designed and developed an Events microservice with a Complex Event Processing engine that processes, correlates and reacts to event streams.

Is your platform close to its ceiling? Discuss your project: the current load, the bottleneck you suspect and the growth you expect. See the projects for the platforms above in full.

What I build

  • Horizontally scalable services. Microservices that scale out independently, behind an API gateway with service discovery and centralized configuration where the platform needs them, and a load balancer in front.

  • Event-driven architecture and messaging. Apache Kafka, RabbitMQ, ActiveMQ, Amazon SQS and Azure Queue; asynchronous task queues in front of heavy workers; Complex Event Processing over event streams.

  • Search at volume. Elasticsearch storage tuned for large datasets, a shared integration library with automated index migrations, and search layers that can switch between Solr and SQL by configuration.

  • Caching. Multi-level caches with reusable results and shared asynchronous computations, Redis, and in-process caches where a network hop costs too much.

  • JVM and performance work. Multi-threaded processing with dedicated worker pools, native libraries through JNI where Java alone is too slow, and CPU-heavy operations on large datasets found and reworked.

  • Fault tolerance and recovery. Workflows that resume from the failed step instead of starting over, isolated tenants, and monitoring, logging and observability for 24/7 production.

The business rules and roles that run on top of such platforms are covered under custom business software development, freight volumes under logistics software, and the running-cost side under internal tools and DevOps tooling.

How I work

I measure before I redesign: the load today, where the time and the money actually go, and what the growth curve looks like. Most platforms have a few hot spots — a storage layout, a CPU-heavy job, a synchronous call that should be a message — and fixing those often comes before any change of architecture, as it did on Turvo. When the architecture itself is the limit, I design the target shape: which parts scale out, what goes through a queue, what is cached and what must stay consistent, and a route to it that keeps production running.

At Itransition I contributed to the design and development of high-load distributed systems; on Vrtly I was the technical owner of the platform architecture and of its production operations; on Soundful I architected the rendering engine and its processing infrastructure. You receive the architecture written down, the services built or rebuilt, and monitoring that shows whether the result holds under real load.

Projects in this domain

Vrtly — Software Architect and Team Lead, 2023. A cloud-based digital signage and advertising platform for healthcare practices and brands, delivering content to smart TVs, streaming devices and media players across distributed installations. I led a team of up to 14 and drove the performance work that reduced resource consumption, improved throughput and lowered infrastructure costs.

Soundful — Software Architect and Team Lead, 2021–2022. An AI-powered music generation platform. Its rendering engine processes musical sections in parallel and individual sounds in dedicated worker pools, reuses cached rendering results, and calls native libraries for pitch shifting, time stretching and encoding; requests flow through asynchronous queues on AWS to separate services for standard and resource-intensive rendering.

Turvo — Software Architect and Lead Software Engineer, 2020–2021. A cloud transportation management system on Spring Boot, MySQL, MongoDB, Redis, Elasticsearch and RabbitMQ on AWS, where I also designed a new microservice with a combined storage approach for scalable processing.

Altir Foundation — 2021–2022. Reusable components for distributed, event-driven applications at a software product studio, on Spring Kafka, RabbitMQ, Esper CEP, Elasticsearch and OpenSearch on AWS. Besides the Events microservice, I designed and implemented an Elasticsearch integration library with automated migration management.

Gulf Relay — Software Architect and Team Lead, 2022–2023. A freight platform on Microsoft Azure, for which I designed and implemented highly scalable microservice-based backend services with Azure Queue and Azure Load Balancer.

Iotatech Claims (CLM) — Software Engineer, 2016–2018. A distributed multi-tenant insurance SaaS with 6 microservices and 3 Angular portals. Engineered a performance-optimized document generation engine handling complex conditional templates and tenant-specific document structures, with automated data population, PDF rendering and AWS S3 integration.

Panaseer — Lead Software Engineer, 2019. A cybersecurity platform that collects and correlates data from many enterprise systems; as part of the team I contributed to the initial architecture and the choice of Apache Kafka and Apache NiFi for its data pipelines.

AMS — Automated Merchant Setup — Software Engineer, 2018–2020. A payment provider's onboarding platform whose workflow engine builds a dependency graph per registration and resumes from the failed node; as an engineer on the team I extended its graph builders with new provisioning nodes.

Frequently asked questions about distributed systems architecture

Do we need microservices?

Not always. A single well-built application is easier to run, and several of my own products are one Spring Boot application. Microservices pay off when parts of the system scale or change at different rates, as with Vrtly's growing screen network or Soundful's rendering workers.

Kafka, RabbitMQ or a cloud queue?

Each has its place: a log you can replay and partition, a broker with flexible routing, or a managed queue with nothing to operate. I have used Apache Kafka on Altir Foundation and Panaseer, RabbitMQ on Turvo and Altir, ActiveMQ on AMS, Amazon SQS on Soundful and Azure Queue on Gulf Relay, and the choice follows the delivery guarantees and the volumes you need.

Can you find out why our platform is slow or expensive?

Yes, and that is usually the first step. Measurements show where the time and the money go; on Turvo the answers were the Elasticsearch storage layout, CPU-intensive operations on large datasets and the utilization of cloud resources.

How long does it take?

A review of a running platform is a short engagement; a change of architecture is planned in stages, each of which leaves production working. The size of the system and the gap between today's load and the target decide the rest.

Need an engineer with experience in distributed systems architecture? Write to me — a few lines about the task are enough — or look through my CV.