Tëma Bolshakov maintains Stoplight, a Ruby circuit breaker library.
In the mid-1990s, ten daycare centers in Haifa had a problem: parents showed up late to pick up their kids. A teacher had to stay late every time, unpaid, waiting. So the daycares ran an experiment. Six of them introduced a small fine for picking up more than ten minutes late. Late pickups didn’t go down. They roughly doubled, and stayed doubled even after the fine was later removed. Why it…
Every circuit breaker tutorial shows the same state machine. CLOSED means healthy, OPEN means failing, HALF-OPEN means testing recovery. Three states, a few transitions, done. The state machine is trivial. The coordination problem hiding beneath it is not. The moment you have concurrent execution–threads in a single process, workers across multiple servers–recovery becomes a coordination problem.…
In the Stoplight 6.0 roadmap , I outlined three major changes: enforcing configuration consistency, UTC timestamps, and cleaner configuration API. These improvements share a common foundation–an architectural pattern called systems. This document explains the architecture behind those changes. If the roadmap answered “what problems are we solving?”, this answers “why is this the right solution,…
I want to talk through some changes we’re planning for Stoplight 6.0 and get your feedback before we finalize anything. There are three design decisions from Stoplight’s early days that keep causing problems in production. They’re not bugs exactly – more like compromises that made sense when the library was younger but now create subtle issues at scale. We’ve been working around them for years,…
It’s 11 PM on Sunday. Your team is on Slack, coordinating the quarterly deployment. The application starts but immediately crashes—turns out the production Redis URL is different from staging. The load balancer health checks are failing because someone changed the endpoint path three commits ago. Your deployment runbook is missing step 7, and nobody remembers what it was supposed to be. This scene…
In our previous article , we discovered how managing transactions at the repository level can lead to dangerous data inconsistencies. A simple user registration system revealed how independently managed transactions could leave our database in an invalid state - an account without its required admin user. Today, we’ll explore a pattern that elegantly solves these challenges while maintaining clean…
Database transactions seem simple at first glance. Create a record, update some fields, commit the changes - what could go wrong? Yet as our applications grow more complex, maintaining data consistency becomes increasingly challenging, especially when multiple operations need to succeed or fail together. Over years of building enterprise applications, I’ve observed teams repeatedly struggle with…
Storing user passwords securely is a well-established practice in software development. We hash passwords instead of storing them as plain text to protect against data breaches and malicious attacks. This allows us to verify user passwords by comparing hash values without ever storing the actual passwords. While hashing works well for passwords, many applications need to store sensitive data that…
Imagine you’re scaling your Ruby application across multiple environments - development, staging, and production. Each environment demands its own configuration, and you need to ensure sensitive data stays secure. As your application grows, managing these configurations becomes increasingly complex. How do you handle this efficiently without compromising on flexibility or security? Enter ConfigX -…
In software engineering, being prepared for rare but critical incidents is essential to maintaining system reliability and minimizing downtime. For our team, ensuring the seamless operation of a data synchronization service was crucial, as it played a vital role in keeping various systems in sync and ensuring the availability of up-to-date information across the organization. When an unexpected…