Three constraints inside one mind. One between minds.

On October 30, 1935, Boeing’s Model 299 crashed on a test flight. It was the most advanced bomber at the time. And it wasn’t a mechanical failure.

Ployer Peter Hill was the pilot. He had tested nearly every military aircraft of the era as the Army’s chief of flight testing.

The investigation found nothing wrong with the aircraft. It was Hill’s first flight on this machine, and he had forgotten to release a mechanism that secured the elevator and rudder controls while the plane was parked. One step, missed in a sequence of more than thirty.

The press called the Model 299 “too much airplane for one man to fly.”

The Army gave the contract to Douglas. Boeing nearly went bankrupt.

The mind behind every system

Human inventions have come a long way. But every system we build still depends on the same instrument. A brain that has not changed in tens of thousands of years.

The human mind is powerful, but constrained. It has a narrow window of active focus. It handles complex work mostly in sequence. It loses what it does not revisit. And when understanding moves between people, it is not copied intact. It is reconstructed.

These are structural properties of human cognition.

Over the past century, cognitive psychology has studied these properties with increasing precision. The following four constraints are my attempt to distill that research into a minimal and orthogonal set.

Three describe the limits of a single mind. The fourth describes what happens at the boundary between minds.

1. Cognitive capacity is structurally bounded

Your mind can hold a small number of items in active focus. The exact number depends on conditions and on what counts as an “item”, but the constraint is stable. Cognitive capacity is narrow. And it does not double because the person is senior. [1]

Experience helps, but not by removing the limit. It helps by compressing more into each slot.

A junior developer sees 50 lines of code. A senior developer recognizes a Circuit Break pattern. An architect sees an availability constraint. A CTO sees a team that reliably handles incidents.

We compress the meaning of many details into a single object that lets us understand, predict and act. The capacity does not change. What fits inside does.

Cognitive capacity matters because many engineering failures happen not when a person knows nothing, but when too many things must be held in mind at once.

A service looks manageable until a deployment depends on one feature flag, two downstream consumers, a migration path, and an undocumented operational exception.

A planning session looks straightforward until the team must juggle business intent, technical debt, ownership boundaries, and half-resolved decisions from last week.

At that point, the problem is not intelligence. The system has exceeded cognitive capacity.

2. Cognitive processing is serial and consumes energy

Human reasoning is not a wide parallel pipeline.

You don’t process a complex procedure in parallel. You inspect one assumption, then the next. You trace one dependency, then another. You compare two interpretations of a requirement. Even when several thoughts feel present at once, careful reasoning still has to move through them in sequence.

That sequence is fragile.

Interruptions do not simply pause thought. They break its continuity. The person loses the place. The question is no longer only “what was I doing?” but “where in the reasoning was I?” Rebuilding that sequence takes effort. [2]

This is why modern engineering work is more exhausting than it often looks from the outside.

The task may be to write code. The real work is holding a chain of reasoning together while Slack interrupts, meetings split the day, CI fails for an unrelated reason, and someone asks for a quick answer that is not quick at all.

We often treat this as a time-management problem. But a system that constantly fragments attention is not just slowing people down. It is repeatedly forcing them to restart the same reasoning from partial state. That is expensive work.

3. Cognitive structures degrade over time

Understanding isn’t stored the way a file is stored. It decays when it is not reinforced.

People forget details. More importantly, they lose structure: why a decision was made, which tradeoff mattered, what exception broke the original rule, what assumptions were made. Without reuse or reinforcement, those structures fade. [3]

A team says, “we already aligned on this.” What they often mean is that the topic was discussed once. Two weeks later, one person remembers the conclusion, another remembers the concern, and a third remembers only that the issue felt resolved.

The same thing happens in codebases.

An engineer who has touched a service every week can navigate it quickly because the mental model is alive. Another engineer opening the same service after six months is not “being slow.” They are rebuilding a model that has decayed through disuse.

This is also why documentation disappoints so often. The problem is not that writing things down is useless. The problem is that static documents do not preserve live understanding by themselves. They help, but only if the surrounding system keeps the knowledge active, revisited, and connected to real decisions.

Knowledge decays. Shared understanding decays faster.

4. Cognitive transfer between agents is lossy and reconstructive

The first three constraints describe a single mind. The fourth appears when understanding has to cross into another.

A product manager explains a goal to an engineering manager. The engineering manager reframes it for a team lead. The team lead turns it into technical tasks. A senior engineer explains edge cases to another engineer in a hurried call. Notes are added. Tickets are updated. A PR description fills in some of the missing context.

The receiving mind does not get a clean copy of the sender’s model. It builds a new model from language, artifacts, prior experience, missing details, and local assumptions. That reconstructed model may be close enough to act on, but it is almost never identical. [4]

And the loss increases quickly with every additional boundary.

Add one more team, one more approval layer, one more handoff, one more dependency on “just ask John, he knows how this works,” and the problem is no longer only complexity in the system. It is complexity in the transfer of reasoning.

Now look at the crash again

Let’s go back to the Model 299 crash with these constraints in mind.

Bounded. Hill understood every system on the plane. But the Model 299 demanded more realtime coordination than one person could reliably hold in focus on a first flight.

Serial. Hill could not run thirty pre-flight steps in parallel. He had to walk through them in order, under the load of a machine he had never flown.

Degraded. This was the first flight in type. Procedures had been studied, not reinforced through repetition. Under pressure, unpracticed steps are the first to go.

Lossy. Hill was not alone in the cockpit. Les Tower, Boeing’s chief test pilot who had helped design the aircraft, was on board. The knowledge existed in the aircraft. It simply did not cross from one mind to another in time to matter.

The crash makes the constraints visible in a single event. The question was what to do about them.

A group of test pilots refused to accept that the airplane itself was unmanageable. They made a checklist — a single index card that walked the crew through every step before takeoff. One small artifact that lowered the load, enforced the sequence, resisted decay, and carried the model from one cockpit to the next.

The B-17 went on to fly thousands of hours without a major accident. Over 12,000 were built.

The same constraints, still ignored

Over twenty years in engineering, I keep seeing the same cognitive failures. Not because people are careless, but because the systems they work in exceed what a human mind can reliably handle.

The industry is not blind to this. Many established practices — small pull requests, bounded contexts, runbooks, on-call rotations — already work by reducing cognitive load. But they are usually framed as craft wisdom or team habits, not as responses to specific, measurable constraints.

In the previous article, I described the widening gap between system complexity and human cognitive capacity — the Cognitive Gap. The place where cognitive debt accumulates and failures cluster.

These four constraints are the next step: making the limits explicit and actionable. Not new rules, but a foundation that explains why the good practices work — and predicts where they’ll fail.

The next article will translate them into design principles.

References

1. Cowan, N. (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. Behavioral and Brain Sciences, 24(1), 87–114.
2. Altmann, E. M., Trafton, J. G., & Hambrick, D. Z. (2014). Momentary interruptions can derail the train of thought. Journal of Experimental Psychology: General, 143(1), 215–226.
3. Ebbinghaus, H. (1885). Über das Gedächtnis; Murre, J. M. J., & Dros, J. (2015). Replication and analysis of Ebbinghaus’ forgetting curve. PLOS ONE, 10(7).
4. Clark, H. H. (1996). Using Language. Cambridge University Press.

Originally published at https://pavelfokin.dev on April 16, 2026.

Complexity scales. Your brain doesn’t.

At 2:32 PM on a Thursday, a senior engineer clicks Merge. His commit takes down billing for half your users.

When the CTO reads the postmortem, it says “human error.” The action item is to add more tests.

What the document won’t mention: at 2:20 PM he was pulled into a quick sync. At 2:25, he was tagged in a Slack thread. At 2:31 PM, a notification about a failing test in another branch. And his attention was already holding three conflicting requirements of the next feature.

It wasn’t a careless mistake. The engineer was operating in a system that exhausted his attention before he clicked the button.

I’ve seen the same patterns in every engineering organization I’ve worked with over the past twenty years. Different stacks, different cultures. The same failures.

The third line

In 2013, Scott Brinker described what he called Martec’s Law: technology changes exponentially, organizations change logarithmically. [1]

Brinker’s two curves describe how organizations fall behind technology. The growing space between those curves is the source of that feeling that your team is always behind. But both curves assume the people inside those organizations can keep up. They can’t.

There’s a line underneath both curves that nobody draws.

For the last hundred thousand years, the human cognitive ability didn’t grow logarithmically. It didn’t grow at all. We’re operating in different environments and thinking about different things. But the number of items a person can hold in mind, the depth of focus they can sustain, the quality of decisions they can make before fatigue — didn’t change.

Technology scales. Organizations adapt slowly. Cognitive capacity stays the same.

• Working memory holds about four items at a time (Cowan, 2001). [2]
• The brain processes information at about 10 bits per second when thinking carefully (Zheng & Meister, 2024). [3]
• A single interruption costs roughly 23 minutes of full focus recovery (Mark, 2008). [4]

These numbers are the same for the intern and the CTO.

The space between exponential complexity and fixed human capacity is what I call the Cognitive Gap. It widens every year, in every engineering organization, regardless of headcount or tooling budget. This is the space where the cognitive debt accumulates.

The Cognitive Gap is not an abstraction. As the gap widens, cognitive debt accumulates: decisions made with incomplete context, knowledge locked in one person’s head, reasoning outsourced to meetings. The usual fixes make it worse. That’s the trap.

How we experience the gap

The Cognitive Gap doesn’t show up as one dramatic failure. It shows up as a series of everyday frictions that everyone accepts as the cost of doing work.

You hired a senior engineer to think. The system doesn’t give them the chance. No clear ownership, tangled dependencies, four approvals for what one person already reasoned through. That’s cognitive waste. Scale that across the org and the problem compounds.

Every company has that one engineer who “just knows how things work.” They answer the Slack questions nobody else can. Important decisions wait for their input. You think they’re your strongest engineer. But it’s the reasoning bottleneck. Remove that person from the room and the problem becomes visible.

Or watch a planning session. The team juggles the latest refactoring, three unresolved dependencies, and half-remembered conversations from last week. They produce an estimate. Two months later it’s off by 3x. And they’ll keep estimating with the same confidence. Not because they’re bad at their job, but because that’s how human decision-making works.

For years I treated these as separate problems. Until I realized they have the same root — the system exceeds what people can reliably think.

Why the best practices miss

It’s always easy to prescribe the best practices.

Knowledge stuck in one person’s head? Write more documentation. But nobody has the cognitive bandwidth to read it, or keep it current.

Estimates are off? Add more detail to requirements. But the team was already at capacity when they sat down to plan.

These interventions aim at behavior. The root cause is structural — how the system is designed.

Your engineers aren’t failing to write good docs. They’re failing to write docs that survive under interrupted, time-pressured, context-switching conditions.

Your meetings aren’t replacing thinking because the team is lazy, but because the system never made thinking cheap enough to happen in other way.

This isn’t a culture problem. It’s a resource management failure — for the one resource nobody manages.

The question that changes everything

We keep asking: “Why is the team slow?”

This leads to predictable answers — not enough process, not enough people, not enough skill. So we hire, train, add process. And the team gets slower, because every new addition increases cognitive load on an already overloaded system.

There’s a better question: “What is consuming their thinking budget right now?”

The team isn’t slow. The team is at cognitive capacity inside a system that demands more than biology allows. You can’t change the hardware. You can only design around it.

The brain is the platform. Everything else is built on top of it. That’s the constraint.

Cognitive-First Engineering is the design response. In the next part, we’ll look at its foundations.

References

1. Martec’s Law: Technology changes exponentially, organizations change logarithmically
2. Cowan, N. (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. Behavioral and Brain Sciences, 24(1), 87–114.
3. Zheng, J., & Meister, M. (2024). The unbearable slowness of being: Why do we live at 10 bits/s. Neuron, 112(3), 1–18.
4. Mark, G., Gudith, D., & Klocke, U. (2008). The cost of interrupted work: More speed and stress. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 107–110.

Originally published at https://pavelfokin.dev on April 1, 2026.

Functional Options is a “gem” among Go patterns

There are a few patterns that feel native in Go. The reason for that is that Go is quite limited in implementing abstractions. And it’s been made with a reason. The reason is to make code more maintainable and easy to read.

That’s why the Functional Options pattern is one of the gems in the Go arsenal.

History

Rob Pike proposed using self-referential functions as options in his blog post in 2014 [1]. Dave Cheney explained a bit more of the motivation for this pattern in his post [2]. The goal was to find the way of creating an extensible and clear API to configure options and not overload the constructor with arguments.

Service

Our example will be a Service struct that has two options host and port. And we want to configure these options with an extensible API.

Structs

Let’s start with defining basic structs.

• Service is a main struct that we need to configure.
• Options is a struct that keeps all options you are interested in.

type Options struct {
  Host string
  Port int
}

type Service struct {
  options *Options
}

Setters

Next, we will need the Setter type. A type of function that is responsible for configuring specific options.

type Setter func(*Options)

func WithHost(host string) Setter {
  return func(opts *Options) {
    opts.Host = host
  }
}

func WithPort(port int) Setter {
  return func(opts *Options) {
    opts.Port = port
  }
}

Constructor

Then let’s implement a function that will initialize a Service structure.

func New(setters ...Setter) *Service {
  // Here we can have default values
  options := &Options{
    Host: "url",
    Port: 8080,
  }

  for _, set := range setters {
    set(options)
  }

  return &Service{
    options: options,
  }
}

Usage

Now, we gather all pieces together to see how it works.

func main() {
  fmt.Println("Functional Patterns")
  service := New(
    WithHost("127.0.0.1"),
    WithPort(5000),
  )
  fmt.Printf(
    "%s:%d\n",
    service.options.Host,
    service.options.Port,
  )
}

And output will be:

➜  go-patterns git:(main) ✗ go run ./basics/funcitonaloptions/.
Functional Patterns
127.0.0.1:5000

Conclusion

At first sight, it looks overkill, but it really just a few extra lines for each new option. And it adds extensibility to your configuration API.

• Let you write APIs that can grow with time.
• Make the default options use case to be the simplest.
• Provide meaningful configuration parameters.

Happy coding!

Full code you can find in my GitHub repo pavel-fokin/go-patterns/basics/funcitonaloptions.

Thank you for reading! Share you thoughts with me on LinkedIn or Twitter.

Further readings

If you like this article you can be interested in the following.

• How to Build a Minimal Golang Docker Image
• What are the limits of Go channels?

References

1. Rob Pike. Self-referential functions and the design of options. https://commandcenter.blogspot.com/2014/01/self-referential-functions-and-design.html
2. Dave Cheney. Functional options for friendly APIs. https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis

Make Docker image less than 10MB

Having an image container that keeps precisely what you need is always considered a best practice. We want to have only our application and dependencies that are required for its runtime.

Why we would do this?

• Small size image reduces the risk of vulnerabilities.
• It will improve the deployment process improve perfomance and reduce size

Minimal Project

I’ll be using a simple HelloWorld webservice to build a Docker image.

Using alpine image

01. Dockerfile

Let’s write a Dockerfile with using an alpine distro as an image.

02. Docker build

After building this Dockerfile we will get a 350MB image.

➜  minimal-docker git:(main) ✗ docker build -t helloworld-large -f Dockerfile.large .
[+] Building 7.1s (12/12) FINISHED
...
...
... 

➜  minimal-docker git:(main) ✗ docker image ls helloworld-large
REPOSITORY         TAG       IMAGE ID       CREATED          SIZE
helloworld-large   latest    678f9303af18   10 seconds ago   350MB

➜  minimal-docker git:(main) ✗ docker run -ti -p 8000:8000 helloworld-large:latest
Server listen 8000...

Can we do better? Yes, we can!

Using distroless image

01. Dockerfile

For the next Dockerfile we will use multistage approach and distroless image by Google.

02. Docker build

Voila! After building we get only 8.6MB image size.

➜  minimal-docker git:(main) ✗ docker build -t helloworld-small -f Dockerfile.small .
[+] Building 8.0s (14/14) FINISHED
...
...
...

➜  minimal-docker git:(main) ✗ docker image ls helloworld-small
REPOSITORY         TAG       IMAGE ID       CREATED         SIZE
helloworld-small   latest    3b035dc2c7e4   5 seconds ago   8.6MB

➜  minimal-docker git:(main) ✗ docker run -ti -p 8000:8000 helloworld-small:latest
Server listen 8000...

Can we do better? Yes, we can!

Using scratch image

01. Dockerfile

We even can go smaller, for this we can use scratch image. But as this is a super slim image we will need to add some extra things as timezones or ssl certificates.

02. Docker build

And we get 7.59MB image.

➜  minimal-docker git:(main) ✗ docker build -t helloworld-xsmall -f Dockerfile.xsmall .
...
...

➜  minimal-docker git:(main) ✗ docker image ls helloworld-xsmall
REPOSITORY          TAG       IMAGE ID       CREATED          SIZE
helloworld-xsmall   latest    b7b554ac46c9   21 minutes ago   7.59MB

Full code you can find in my GitHub repo pave-fokin/go-patterns/minimal-docker.

Happy coding!

Thank you for reading! Share you thoughts with me on LinkedIn or Twitter.

Further readings

If you like this article you can be interested in the following.

• How to Embed React App into Go Binary
• What are the limits of Go channels?

All that is mine I carry with me

Image that you have an amazing project with React app, and you want to distribute and deploy it along with you Go application.

Let’s say that it is a super cool LikeIt! project, and it allows to like a page ¯\_(ツ)_/¯.

01 Project structure

First, lets review the project structure.

In the root of the project we have the main.go file. This is the entry point and keeps all the go code.

• main.go — is in the root of the project and this is an entry point for our Go app.
• /web — directory keeps code and assets for the React app.
• /web/dist — is an empty directory that will keep built web assets.

For this example I‘m using Parcel to build a web part.

02 Go “embed” package

Since go-1.16 standard library includes embed package. This package provides access to files embedded in the running Go program.

With the usage of //go:embed directive, we can initialize a variable of type string, []byte, or FS. A variable can keep content of the file or the whole directory.

For more examples check the package documentation.

03 How to serve static files

Embed package implements FS interface, so it can be used with any package that understands file systems, including net/http, text/template, and html/template.

That means that we can use built-in http.FileServer to serve our embedded files.

04 Results

As the result we can build a Go binary that keeps all our static files.

➜  likeit git:(main) ✗ go build -o bin/likeit main.go
➜  likeit git:(main) ✗ ls -lh bin/likeit
-rwxr-xr-x  1 pavel-fokin staff   6.6M Jul 23 16:48 bin/likeit

And it can be deployed as heroku app -> likeit-click.

Full code you can find in my GitHub repo pavel-fokin/likeit.

Thank you for reading! Share you thoughts with me on LinkedIn or Twitter.

Further readings

If you like this article you can be interested in the following.

• What are the limits of Go channels?
• Why Do Programming Languages Have Types?

By the message size, maximum allocation, and performance

Did you ever think about the limits of Go channels? I decided to look into the golang repo to find out how channels are created.

Here is what I found out.

Making a channel

I started by looking for the code of the function that creates a channel. Not surprisingly I could find it in the runtime/chan.go file.

Function makechannel has the following signature.

Then let’s review what are the chantype and hchan types.

Channel types

A chantype is a wrapper for a _type struct.

A _type type is an underlying struct for any go type, and it looks as follows.

Then let’s take a look on the hchan type.

Let’s move forward and look into the makechan function.

Message size

When we start from the beginning of the makechan function. We can see that it checks for a size of the future channel’s message.

And the maximum message size is 2¹⁶ bytes, or 64 kilobytes.

Maximum allocation

The next step is to check the size of the memory that can be allocated for a new channel.

What is the maxAlloc size?

The maxAlloc determines the maximum memory size that is theoretically allowed. On the 64-bit Unix-like systems this is 2⁴⁷ bytes (~140 Terabytes).

Though, it allows allocating up to 140 Terabytes. You will meet the memory issues if you will try to do so 😄.

Performance

By the following naive benchmark, we can measure the upper limits for the send/receive operations.

The send and receive operations are mainly spending time in the goroutine’s context switching. On my machine, this number is stably <100 ns.

➜  channels git:(main) ✗ go test -bench=.
goos: darwin
goarch: arm64
pkg: pavel-fokin/go-patterns/concurrency/channels
BenchmarkUnbufferedChannelInt-8         11091662               107.5 ns/op
BenchmarkBufferedChannelInt-8           15082126                80.11 ns/op
PASS
ok      pavel-fokin/go-patterns/concurrency/channels    7.021s

Final thoughts

Looking into the Go internals is definitively worth it. You not only can see the details of implementation but also learn best practices.

Happy coding!

Further readings

If you like this article you can be interested in the following.

• How to Implement Mediator Pattern in Go
• Why Do Programming Languages Have Types?

Behavioral Design Patterns in Go

Sometimes we have a bunch of objects that need to interact with each other. A number of objects can be large and their interactions can have complex logic.

Mediator pattern helps to organize such cases.

• Mediator lets keep loose coupling and don’t let objects have direct communication.
• Mediator keeps the interaction logic and allows to change it independently.

Let’s look for an example!

A chat

For example, we have a bunch of Users and they want to interact with each other.

• A User can send a message to another User.
• A User can send a message to all Users.
• Some Users can be unavailable for messaging.

So we introduce a Chat object that keeps this logic and organizes communication.

User type

Firstly, we will introduce a User type. It will have a Name and store Messages.

Chat type

Then we need a Chat type. It will have a method to Add a User and keep information about Users in the Chat. This is our Mediator.

Interaction logic

Now, let’s extend our Chat with interaction logic.

• Say(to User, msg string) - sends a message to the specific User and handles an error if the User is not in the Chat.
• SayAll(msg string) - sends a message to the all available Users.

Usage Example

Now, we gather all pieces together to see how it works.

Conclusion

Mediator pattern is a good example of encapsulation logic into separate entity. It’s a complement to the Observer pattern. In real world applications though the logic can grow a lot, and turn this into God object antipattern.

Happy coding!

Code examples can be found in my GitHub repo pavel-fokin/go-patterns.

More reading

If you like this article you can be interested in the following.

• Why Do Programming Languages Have Types?
• How to Implement Memento Pattern in Go

Originally published at https://pavelfokin.dev.

Behavioral Design Pattern in Go

Let’s take a look at the problem. We have some object and we want to be able to save and restore its state. And we want to have a good design for it.

• We want to have a separation of concerns, different logic has to have different owners.
• We don’t want to break an encapsulation of the object and hide direct access to its state.

The Memento pattern is for the rescue!

Tasks

For example, we have a type that keeps a list of Tasks. We don't have direct access to the list of tasks, and we have implemented the Add method.

Memento

As the first step, we will introduce a new type — Memento. This is the box that can keep a list of tasks. This list is also private and we have a specific method to access it.

The Memento object has to be as simple as possible and it doesn't have any other logic.

Improve Tasks

The next step will be improving the Tasks object. We'll need to implement two additional methods.

• Memento() - it creates a Memento instance that keeps the current Tasks state.
• Restore(m Memento) - this method can restore a Tasks' state from a Memento instance

History of Changes

The next object we implement will be a History type. This type keeps a stack of Memento objects.

Implementing this type is not required by the classical Memento pattern. But I think it’s good to have it for a cleaner example.

Usage Example

In this example, the main function knows why and when the Tasks need to save and restore itself.

In the general case, it can be an additional type that keeps that logic.

And output will be

# Output
➜  go-patterns git:(main) go run ./behavioral/memento
[Task 1 Task 2]
[Task 1]
[]

Conclusion

Implementation of a basic Memento Pattern is a good example of separation of concerns. It keeps encapsulation of the initial object and extends its functionality with new logic.

Happy coding!

Code examples can be found in my GitHub repo pavel-fokin/go-patterns.

More reading

If you like this article you can be interested in the following.

• How to Implement Mediator Pattern in Go
• How to Implement Observer Pattern in Go
• Why Do Programming Languages Have Types?

Originally published at https://pavelfokin.dev.

A way to reason about software quality

When we start to develop software, we usually care about its quality.

Software quality is often divided into Functional and Non-functional.

Functional quality is what software can do for its users.

Non-functional is everything else that helps the software to serve its functions. And it includes a lot of things. Among them are the code quality, maintainability, how easy we can deploy software, how secure it is, and much more.

When we think about quality, we want to have some measurable characteristics. This gives us ability to make reasonable and data-driven decisions.

Availability

Let’s look at availability. This is the fraction of the time when service is usable.

For example, we can find it for a web service as the ration of successful requests to the all requests. By successful requests we mean requests that are not 5xx.

Well, what these numbers can give us?

When we design a solution.

When we are discussing system design. We can make choices about the components for our systems.

For example, we can check that droplets in Digital Ocean have 99.99% SLO, or that single instance of Google Compute Engine has low bound 99.5% availability in a month.

Basically, we can check availability for different cloud components in AWS or Google Cloud. We can ask how many users will be effected if we will be unavailable for 10 minutes each week.

When we maintain a system.

• We can improve our strategies with deployments. We will have metric for this.
• We can have a focus on the critical parts of the system with higher availability.
• We can change our technical solution to complain with required availability.

SLI

An SLI is a service level indicator — a measurable metric of some aspect of service.

The measurements are often aggregated: raw data is collected over a time window and turned into a rate, average, or percentile.

Examples:

• Availability is the fraction of the time that a service is usable.
• Request latency — how long it takes to return a response to a request. 99th percentile for latency will be example of such indicator.

SLO

An SLO is a service level objective is a target value for a service level that is measured by an SLI.

For example:

• 30 days availability ≤ 99.9%
• P99 Latency for 99.9% of requests < 1 sec

SLA

An SLA is a service level agreement is a contract with your users that includes consequences of meeting (or missing) the SLOs.

An easy way to tell the difference between an SLO and an SLA is to ask “What happens if the SLOs aren’t met?”.

The consequences are most easily recognized when they are financial — a rebate or a penalty.

But also it can be internal policies. For instance, a team can freeze implementation of the new features until availability will be fixed.

Final thoughts

SLIs, SLOs, and SLAs are the great tools that allow us to work with quality of service.

• Solid SLOs helps us to design better system.
• Right SLOs gives a team confidence that a service is healthy.
• Choosing appropriate SLOs helps to make the right action if something goes wrong.

Thank you for reading! Share you thoughts with me on LinkedIn or Twitter.

Further reading

You can find more info at this article from the Google SRE Engineers.

Google - Site Reliability Engineering

Originally published at https://pavelfokin.dev.

What are SLIs, SLOs, and SLAs? was originally published in Mindware Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.