The second part of the Scalability Series explains why a correctly sized service still breaks down under load. According to Kingman’s formula, as workload increases, variability in service times leads to a significant increase in response times and the creation of phantom traffic jams in the queue, which occurs long before the theoretical capacity limit is reached..
Hi, I'm Guido. I develop large-scale e-commerce systems at OTTO and write about what works, what doesn't, and why.
Teil 2: Kingmans Formel
Der zweite Teil der Skalierbarkeit-Serie erklärt, warum ein korrekt dimensionierter Service trotzdem unter Last einbricht. Kingmans Formel zeigt: Variabilität in den Servicezeiten führt bei steigender Auslastung zu einer vervielfachung der Antwortzeiten – und erzeugt Phantomstaus in der Warteschlange, lange bevor die theoretische Kapazitätsgrenze erreicht ist.
Digression: Zipf's Law and the Limits of Caching
Caching is the first instinct when dealing with performance and load issues – and it usually helps dramatically. But the capacity gained isn’t down to the system itself, but to the traffic pattern. Zipf’s Law explains why hit rates of 80–95% aren’t the result of good implementation, but rather the result of ‘normal’ human behaviour. And why a single bot with the ‘wrong’ access pattern can bring an entire shop to its knees.
The new instalment in the Scalability Series shows why caching is a powerful performance tool – but not a scaling principle.
Exkurs: Zipf's Law und die Grenzen des Cachings
Caching ist der erste Reflex bei Performance- und Last-Problemen – und meistens hilft es spektakulär. Aber die gewonnene Kapazität gehört nicht dem System, sondern dem Traffic-Muster. Zipf’s Law erklärt, warum Hit-Rates von 80–95% kein Verdienst guter Implementierung sind, sondern das Resultat “normalen” menschlichen Verhaltens. Und warum ein einzelner Bot mit dem „falschen” Zugriffsmuster einen ganzen Shop in die Knie zwingen kann.
Der neue Exkurs zur Skalierbarkeits-Serie zeigt, warum Caching ein mächtiges Performance-Werkzeug ist – aber kein Skalierungsprinzip.
Part 1: Little's Law in Practice
The first part of the Scalability Series is now available. A formula from 1961 – L = λ × W – links three metrics that describe any system: throughput, latency, and parallelism. If you want to understand why a service crashes under load or how to estimate its performance, this is the place to start.
Teil 1: Little's Law in der Praxis
Der erste Teil der Scalability-Serie ist da. Eine Formel aus dem Jahr 1961 – L = λ × W – verbindet drei Größen, die jedes System beschreiben: Durchsatz, Latenz und Parallelität. Wer verstehen will, warum ein Service bei Last zusammenbricht, oder wie sich die Leistungsfähigkeit eines Services abschätzen lässt, fängt hier an.
A New Series: Scalability
Sometime around 2005, a portal I’d helped to build crashed when it reached 50 concurrent users. Around then, the “New Market” was booming, and everywhere you looked, there were stories of companies serving millions of users. What did they know about software architecture that I didn’t?
The topic of scalability has been with me for over twenty years now. This new series is where I’ll be writing down what I’ve learnt along the way – from the mathematical fundamentals that every developer would understand, to the organisational structures that determine whether a company can even develop and operate systems of this scale.
The series kicks off with the article Fifty Users, in which I introduce the fundamental concepts and challenges of scalable systems. In the coming weeks, further articles will follow on topics such as backpressure, Little’s Law, Kingman’s formula and much more.
Eine neue Serie: Scalability
Irgendwann um 2005 brach ein Portal, an dem ich mitgebaut hatte, bei 50 gleichzeitigen Nutzern zusammen. Gleichzeitig boomte der “Neue Markt” und überall las man von Unternehmen, die Millionen von Nutzern bedienten. Was wussten die über Software-Architektur, was ich noch nicht wusste?
Das Thema Skalierbarkeit begleitet mich mittlerweile schon über zwanzig Jahre. In einer neuen Serie will ich aufschreiben, was ich dabei gelernt habe – von den mathematischen Grundlagen, die jedem Entwickler verständlich sind, bis zu den organisatorischen Strukturen, die darüber entscheiden, ob das Unternehmen Systeme dieser Größenordnungen überhaupt entwickeln und betreiben kann.
Den Auftakt der Serie macht der Artikel Fünfzig Nutzer, in dem ich die grundlegenden Konzepte und Herausforderungen von skalierbaren Systemen vorstelle. In den kommenden Wochen folgen weitere Artikel zu Themen wie Backpressure, Little’s Law, Kingman’s Formel und vielem mehr.
OTTO im Wandel – Serie im Java Magazin
🇩🇪Zusammen mit Martin Kalsow und Christian Finckler habe ich eine vierteilige Serie für das Java Magazin geschrieben – über OTTOs technische und organisatorische Transformation der letzten 15 Jahre. Vom monolithischen E-Commerce-System zur skalierbaren, cloud-nativen Microservice-Architektur.
Scaling Agile @ OTTO
🇬🇧How OTTO scaled agile development from 4 to over 40 cross-functional teams – covering triads, product ownership, DevOps culture, and the limits of growth. Originally published on dev.otto.de.
Why Microservices?
🇬🇧A follow-up to the monoliths article: why we believe in microservice architecture at OTTO, what problems it solves, and what trade-offs come with it. Originally published on dev.otto.de.
On Monoliths and Microservices
🇬🇧My first article about OTTO’s architecture – how we moved from a monolithic e-commerce platform to self-contained systems and microservices. Originally published on Informatik-Aktuell and dev.otto.de.