Serhiy Morenko
Software engineer and a maintainer of the @imqueue framework, working on the RPC, tooling and service internals.
// POSTS BY SERHIY MORENKO
One notification, every replica: the LISTEN/NOTIFY duplicate problem
LISTEN/NOTIFY is a broadcast, not a queue. Scale a Node app to three replicas and the same notification gets handled three times — no error, no warning, three charges on the card. Here's why, and what an inter-process lock actually does about it.
read →Auto-scaling Redis broker: with and without broadcast
One Redis behind your message bus is a ceiling and a single point of failure. The promoter and unicaster modules turn a fleet of plain Redis instances into a horizontally auto-scaling broker — here are the recipes for networks that deliver broadcast and for clouds like GCP that don't.
read →RPC over Redis in Node.js: patterns and pitfalls
How request/reply RPC over Redis actually works in Node.js — the correlation, timeout and delivery problems you have to solve yourself, why the old npm packages stalled, and how @imqueue turns it into typed, boilerplate-free calls.
read →Type-safe service-to-service communication in TypeScript
End-to-end types across service boundaries are easy inside one process and hard the moment you cross a network. Here's how to keep them without hand-writing clients or maintaining a schema language.
read →Stop hand-writing and maintaining your microservice clients
Every service you call needs a client, and hand-maintained clients drift out of sync with the services they talk to. Here's why that happens, how to make the client fall out of the service, and what the generated approach costs.
read →Cutting the boilerplate out of Node.js microservices
Most of a new service's first commit is ceremony — transport wiring, serialization, a client, CI, a Dockerfile. Here's where the boilerplate hides and how to stop writing it by hand.
read →Versioning microservices without breaking every caller
A change to one service's method quietly breaks the services that call it — and you find out in production. Here's how to make breaking changes loud at build time, which changes are actually safe, and how to handle the window where both versions are live.
read →Testing services that call each other
Integration tests that require every service and its infrastructure running are slow, flaky, and painful. Here's a layered approach that tests most of your logic without spinning up the world.
read →