Oleksandr Andrushchenko

@oleksandr-andrushchenko

Software Engineer & Solution Architect

Website: oleksandr-andrushchenko.com

GitHub: oleksandr-andrushchenko

Buy Me a Coffee: oleksandr.andrushchenko

Location: The Colony, TX

Joined: Nov 03, 2025

6 Followers

3 Following

184 Articles

0 Comments

6 Followers

3 Following

About

Software Engineer with experience building and optimizing scalable applications across healthcare, fintech, e-commerce, media, and logistics. Skilled in Python, JavaScript/TypeScript, PHP, cloud architecture (AWS Certified Solutions Architect & Developer), and database design (RDBMS, NoSQL). Delivered 40+ projects, improving performance, scalability, and reliability. Experienced in architectural decision-making and driving projects from concept to deployment.

371 activities in the past year

Year

Enjoy this author’s work?

Support Oleksandr Andrushchenko

Buy me a coffee

This helps Oleksandr Andrushchenko continue creating useful content

Interests

reliability aws tls scalability aws-lambda amazon-ecs databases serverless protocols dynamodb postgresql nosql kubernetes infrastructure production-systems

Latest Articles

Kafka Best Practices for Production Systems

Kafka Best Practices for Production Systems

Running Kafka in production is less about finding a perfect configuration and more about designing predictable behavior under load, failures, deployments, retries, and traffic growth. Partitioning, producer durability, consumer idempotency, schema evolution, retention, and observability all affect w

Oleksandr Andrushchenko Sep 09

kafka best-practices distributed-systems

20 Core Agentic Engineering Concepts Every Developer Should Understand

20 Core Agentic Engineering Concepts Every Developer Should Understand

Agentic engineering is the discipline of building AI systems that can reason about goals, choose actions, use tools, observe results, maintain state, and continue working until a task reaches a useful outcome. The difficult part is not making a model generate text; it is designing the control system

Oleksandr Andrushchenko Sep 09

agentic-ai ai-agents agentic-engineering

Kafka Schema Evolution and Event Versioning

Kafka Schema Evolution and Event Versioning

Kafka events often live much longer than the code that originally produced them. Producers and consumers deploy independently, retained records may be replayed months later, and new consumers may start by reading historical events created by older application versions.

Oleksandr Andrushchenko Sep 09

kafka schema-evolution event-versioning

Kafka Ordering Guarantees and Message Deduplication

Kafka Ordering Guarantees and Message Deduplication

Kafka preserves record order inside a partition, not across an entire multi-partition topic. That distinction affects partition-key design, consumer concurrency, retries, scaling, and every workflow where events must be applied in a predictable sequence.

Oleksandr Andrushchenko Sep 09

kafka message-ordering idempotency

Kafka Reliability: Retries, Dead Letter Topics, and Failure Handling

Kafka Reliability: Retries, Dead Letter Topics, and Failure Handling

Kafka keeps events durable, but durable transport does not make event processing reliable by itself. Consumers still need a failure strategy for database timeouts, malformed payloads, external API outages, rate limits, poison messages, and business errors that will never succeed on retry.

Oleksandr Andrushchenko Sep 08

kafka reliability distributed-systems

Kafka Performance and Scaling

Kafka Performance and Scaling

Kafka performance depends on how producers batch records, how partitions distribute work, how brokers use disk and network, and how fast consumer groups can process data. Scaling Kafka successfully requires identifying which layer is saturated instead of assuming that more brokers or more partitions

Oleksandr Andrushchenko Sep 08

kafka scalability performance

Designing Event-Driven Systems with Kafka

Designing Event-Driven Systems with Kafka

Kafka makes it possible to connect services through durable event streams instead of synchronous request chains. The difficult part is not publishing records; it is deciding what should be an event, who owns it, how services change state safely, how failures are retried, and how schemas evolve witho

Oleksandr Andrushchenko Sep 08

kafka event-driven-architecture distributed-systems

Kafka Replication and Fault Tolerance Explained

Kafka Replication and Fault Tolerance Explained

Kafka fault tolerance is built around partition replication. Instead of storing a partition on only one broker, Kafka keeps multiple replicas across brokers so another replica can take over when the current leader becomes unavailable.

Oleksandr Andrushchenko Sep 07

kafka fault-tolerance distributed-systems

Kafka Delivery Semantics: At-Most-Once, At-Least-Once, and Exactly-Once

Kafka Delivery Semantics: At-Most-Once, At-Least-Once, and Exactly-Once

Kafka delivery semantics describe what can happen to a record when producers, brokers, consumers, networks, or downstream systems fail. The familiar terms at-most-once , at-least-once , and exactly-once are useful only when the processing boundary is defined precisely.

Oleksandr Andrushchenko Sep 07

kafka distributed-systems event-streaming

Kafka Consumers and Consumer Groups Explained

Kafka Consumers and Consumer Groups Explained

Kafka consumers turn durable event streams into application work. They fetch records from partitions, process them, track progress through offsets, and cooperate through consumer groups to divide a topic across multiple application instances.

Oleksandr Andrushchenko Sep 07

kafka event-streaming distributed-systems

Kafka Producers Explained: Partitioning, Batching, and Delivery Guarantees

Kafka Producers Explained: Partitioning, Batching, and Delivery Guarantees

A Kafka producer does much more than send individual messages to a broker. It chooses partitions, accumulates records into batches, compresses data, retries failed requests, waits for acknowledgements, and can prevent many retry-generated duplicates through idempotent publishing.

Oleksandr Andrushchenko Sep 07

kafka event-streaming distributed-systems

Kafka Topics, Partitions, and Offsets Explained

Kafka Topics, Partitions, and Offsets Explained

Kafka topics, partitions, and offsets define how data is organized, scaled, ordered, consumed, and replayed. Most Kafka design mistakes eventually come back to one of these three concepts.

Oleksandr Andrushchenko Sep 07

kafka distributed-systems event-streaming

Apache Kafka Explained: How Kafka Works

Apache Kafka Explained: How Kafka Works

Apache Kafka is a distributed event-streaming platform designed for moving large volumes of records between systems while keeping those records durable, ordered within defined boundaries, and available for later replay.

Oleksandr Andrushchenko Sep 07

kafka event-driven-architecture distributed-systems

Caching Best Practices for Production Systems

Caching Best Practices for Production Systems

Caching improves latency and reduces pressure on databases, APIs, storage systems, and expensive computations by keeping frequently needed data closer to where it is consumed. In production, however, adding a cache also creates another copy of data that can become stale, inconsistent, overloaded, or

Oleksandr Andrushchenko Sep 06

caching performance production-best-practices

System Design Interview: How Would You Design a Real-Time Leaderboard for Millions of Users?

System Design Interview: How Would You Design a Real-Time Leaderboard for Millions of Users?

A leaderboard looks simple at small scale: store each user's score, sort by score, and return the first 100 rows. At millions of users and thousands of score updates per second, that approach becomes expensive quickly.

Oleksandr Andrushchenko Sep 06

leaderboards distributed-systems system-design-interviews

System Design Interview: How Would You Implement an API Rate Limiter in a Distributed Environment?

System Design Interview: How Would You Implement an API Rate Limiter in a Distributed Environment?

An API rate limiter sounds simple: count requests and reject clients that exceed a limit. The design becomes much harder when requests are handled by dozens or hundreds of application instances across multiple servers, availability zones, or regions.

Oleksandr Andrushchenko Sep 06

system-design-interviews rate-limiting distributed-systems

System Design Interview: How Would You Prevent a Payment from Being Processed Twice?

System Design Interview: How Would You Prevent a Payment from Being Processed Twice?

A payment request times out. The customer sees an error and presses Pay again. The first request may have failed, or it may have successfully charged the card while only the response was lost.

Oleksandr Andrushchenko Sep 05

payments idempotency system-design-interviews

Full-Text Search vs SQL Search

Full-Text Search vs SQL Search

Many applications begin with search implemented directly in a relational database. A query such as WHERE title LIKE '%database%' is easy to build, requires no additional infrastructure, and may work perfectly well for a small dataset.

Oleksandr Andrushchenko Sep 01

search-engines sql elasticsearch

Designing High-Performance Search Systems

Designing High-Performance Search Systems

A search system can return correct results and still fail in production if latency grows under load, indexing falls behind, hot shards overload individual nodes, or expensive queries consume too much CPU and memory.

Oleksandr Andrushchenko Sep 01

search-engines performance-optimization system-design

Search Relevance and Ranking Strategies

Search quality depends on more than finding documents that contain the query terms. A production search system must decide which matching results deserve to appear first.

Oleksandr Andrushchenko Sep 01

search-engines ranking information-retrieval

Scaling Elasticsearch Clusters

Scaling Elasticsearch Clusters

Elasticsearch can scale from a small single-node deployment to clusters serving billions of documents, but horizontal scaling is not automatic. Adding nodes without understanding shard layout, workload distribution, recovery behavior, and memory pressure can make a cluster more complex without makin

5.0/5 (1)

Oleksandr Andrushchenko Sep 01 1

elasticsearch search-engines scalability

Autocomplete and Suggestion Systems

Autocomplete and Suggestion Systems

Autocomplete looks simple because the interface is small: a user types a few characters and the system returns a short list of likely completions. In production, however, autocomplete is a latency-sensitive search problem with very different requirements from ordinary full-text search.

5.0/5 (2)

Oleksandr Andrushchenko Sep 01 2

search-engines autocomplete system-design

Search Best Practices for Production Systems

Production search systems fail in more ways than returning the wrong document. They can become slow under load, fall behind on indexing, overload databases, produce stale results, create hot shards, return inconsistent rankings, or become impossible to tune because nobody knows why a result was rank

Oleksandr Andrushchenko Sep 01

search-engines production-systems system-design

Search Engines Explained: How Modern Search Works

Search Engines Explained: How Modern Search Works

Search looks simple from the outside: enter a query and receive a list of relevant results. Behind that interface is a specialized data-processing system designed to find useful documents across millions or billions of records within milliseconds.

Oleksandr Andrushchenko Sep 01

search-engines full-text-search-engines elasticsearch

Kubernetes Pros and Cons

Kubernetes Pros and Cons

Kubernetes has become one of the standard platforms for running containerized applications at scale. It provides scheduling, service discovery, load balancing, automated deployments, scaling, self-healing, configuration management, and infrastructure abstraction through a common declarative API.

5.0/5 (1)

Oleksandr Andrushchenko Sep 01 1

kubernetes containers devops

Strategies to Share Data Between Services

Strategies to Share Data Between Services

Splitting an application into services creates an important architectural problem: each service owns its data, but other services frequently need that data to complete their work .

5.0/5 (1)

Oleksandr Andrushchenko Sep 01 1

microservices distributed-systems data-sharing

Storage Best Practices for Production Systems

Storage Best Practices for Production Systems

Production storage must remain reliable while data volume grows, hardware fails, workloads change, and background operations compete for capacity. A storage architecture that performs well during normal traffic can still fail when a node disappears, a volume fills, replication falls behind, or recov

Oleksandr Andrushchenko Aug 31

storage-systems reliability production-systems

Data Lifecycle Management

Data Lifecycle Management

Production systems rarely keep every byte of data forever in the same storage tier. Transaction records, application logs, uploaded files, analytics datasets, backups, and temporary artifacts have different values as they age. Keeping all of them on high-performance storage increases cost, operation

Oleksandr Andrushchenko Aug 31

storage-systems data-archiving data-lifecycle-management

Storage Performance Optimization

Storage Performance Optimization

Storage performance is determined by more than disk speed. Production latency depends on the entire I/O path: application access patterns, filesystem behavior, operating-system caches, storage queues, network latency, replication, device characteristics, and background workloads.

0.0/5 (1)

Oleksandr Andrushchenko Aug 31 1

storage-systems performance-optimization scalability

Replication, Snapshots, and Backup Strategies

Replication, Snapshots, and Backup Strategies

Replication, snapshots, and backups all protect data, but they protect against different failure modes . Treating them as interchangeable creates one of the most dangerous storage architecture mistakes: a system can have several replicas and frequent snapshots while still having no reliable recovery

Oleksandr Andrushchenko Aug 31

storage-systems data-replication data-backup-and-recovery

Designing Reliable File Storage Systems

Designing Reliable File Storage Systems

A reliable file storage system must do more than persist files. It must preserve data integrity, namespace consistency, availability, predictable latency, and recoverability while clients concurrently create, read, modify, rename, and delete files.

Oleksandr Andrushchenko Aug 31

storage-systems distributed-systems reliability

Object Storage vs File Storage vs Block Storage

Object Storage vs File Storage vs Block Storage

Choosing between object, file, and block storage is an architectural decision about access patterns, latency, consistency, scalability, and operational semantics . All three ultimately persist bytes, but they expose those bytes differently and therefore behave very differently under production workl

Oleksandr Andrushchenko Aug 31

storage-systems system-design cloud-storage

Storage Systems Explained: Block, File, and Object Storage

Storage Systems Explained: Block, File, and Object Storage

Storage architecture affects far more than where bytes are persisted. The storage model influences latency, throughput, consistency, failure recovery, scalability, operational complexity, and cost . A poor storage choice can become an architectural bottleneck long before CPU or network capacity beco

Oleksandr Andrushchenko Aug 31

storage-systems system-design distributed-systems

Networking Best Practices for Production Systems

Networking Best Practices for Production Systems

Production networking is not only about making services reachable. A reliable network architecture must continue operating when instances fail, traffic spikes, dependencies become slow, DNS changes, connections accumulate, certificates rotate, or entire failure domains become unavailable.

Oleksandr Andrushchenko Aug 30

networking production-best-practices reliability

TLS, HTTPS, and Secure Communication

TLS, HTTPS, and Secure Communication

Network traffic often crosses infrastructure that is not controlled by the application: Wi-Fi networks, ISPs, corporate proxies, cloud networks, load balancers, and internet routing infrastructure. Without transport security, attackers on the network path may be able to read traffic, modify requests

Oleksandr Andrushchenko Aug 30

tls https network-security

DNS, Load Balancers, and Reverse Proxies

DNS, Load Balancers, and Reverse Proxies

Production traffic rarely travels directly from a client to an application server. A request typically passes through several network layers responsible for finding the service, selecting healthy capacity, terminating connections, and routing the request to the correct backend .

Oleksandr Andrushchenko Aug 30

dns load-balancing reverse-proxy

Designing Highly Available Network Architectures

Designing Highly Available Network Architectures

Highly available network architecture is designed so that the failure of a single host, network device, availability zone, gateway, or traffic path does not make an application unreachable.

Oleksandr Andrushchenko Aug 30

networking high-availability reliability