Reactive

Introduction Part 1 compared the architectural foundations of Kafka and Pulsar — storage models, subscription types, multi-tenancy, and client design. That was theory. This post puts those differences under load. We will run the same workloads against both brokers on identical hardware, using a reactive benchmark framework built with Project Reactor. The goal is not to crown a winner — it is to see where architectural decisions become measurable. Specifically, we will look at: ...

The Problem with Waiting Large language models are slow. A typical response takes seconds — sometimes tens of seconds — to generate. During that time, the user stares at an empty chat window, wondering if anything is happening at all. Every major LLM chat interface solved this the same way: stream tokens as they arrive. ChatGPT, Claude, Gemini — they all render partial text while the model is still thinking. The experience feels responsive even when the full response takes 15 seconds. ...

From Design to Implementation In the previous article, I outlined the design goals and high-level architecture of a reactive Telegram bot framework — why non-blocking I/O matters, how separating polling from processing enables horizontal scaling, and why sealed interfaces make response dispatch type-safe at compile time. That article showed simplified code to explain the concepts. This one goes deeper. We will walk through the actual implementation: how Flux.create and expand drive the polling loop with back-pressure, how atomic variables coordinate concurrent state without locks, how the channel abstraction separates read and write concerns, and how Apache Pulsar’s reactive client integrates natively with Project Reactor. ...

Why another Telegram bot framework? Building Telegram bots is straightforward — the API is well-documented, and there are dozens of libraries in every language. However, most existing Java frameworks share the same fundamental limitation: they process updates sequentially on blocking threads. This works fine for hobby projects handling a few messages per minute, but it becomes a bottleneck the moment your bot needs to serve thousands of concurrent users, handle complex multi-step workflows, or integrate with other microservices in a distributed system. ...

Why Stream at All The traditional Spring MVC model serializes the entire response into memory before sending it. A controller returns a List<Message>, Jackson converts it to a JSON array, and the framework writes the complete byte buffer to the socket. This works until the dataset is large, the source is slow, or both. Consider a database query that returns 10,000 rows. The blocking approach loads all rows into a List, serializes the entire JSON array, and only then begins writing to the client. Memory usage spikes, time-to-first-byte suffers, and the client waits for the slowest row before seeing anything. ...

Introduction This article tests three distinct Spring Boot application architectures: Classic Servlet App (Servlet) Reactive RSocket Motivation HTTP is a widely used transport for APIs, and it has pros and cons. It’s old and has big performance issues, but it is still widely used because of its ease of use. Assumptions Basic applications without best practices implementation Tests may not be identical in every aspect JVM parameters remain unoptimized for each application type Requirements Accept messages, receive lists/streams, save to database with empty response List messages by author with return of all messages Identical data feeds across all tests Measure requests per second (RPS) Message Format: ...

Business needs first Goals The primary objective for every software engineer is not to provide solutions with the latest modern library or architecture, the main goal is to help businesses to solve their problems. To achieve this software engineers need to provide solutions that will efficiently help to solve business problems with minimum errors and optimum costs that will help businesses be profitable in the end. This goal is critical and directly informs how we allocate our resources and design our systems. ...