Satisfactory, a PC game from Coffee Stain Studios, is a game about efficiency. You are given an unlimited supply of raw materials and the ability to build machines that transform or combine materials into products at different rates. These products can then be fed through other machines to produce even more complex items. Your goal is to scale the system to a massive size while wasting as few resources per minute as possible.

Website cloud architecture is a much more complex field, but one of its tenets is about efficiency. You are given an unlimited supply of incoming requests from users and the ability to build services that transform these requests into responses. These services might depend on other, smaller services, which produce responses of their own. One of your many goals is to scale the system to a massive size while introducing as little latency as possible.

It’s no surprise that playing Satisfactory can make you better at website architecture, and vice versa. Today, I’m going to go over what the two have in common to give you a jump-start in either (or both).

What are our tools?

There are four main types of game objects in Satisfactory:

Machines. Each machine has a set number of inputs, a single output, and a maximum throughput. Machines that are being fed more than their maximum will refuse additional incoming resources, causing a backup.

Storage. Storage containers can hold any item, but are limited to a single input and output. They also have a maximum capacity.

Belts. Conveyor belts are used to connect everything together. Each belt has a maximum throughput.

Balancers. Belt splitting and merging machines can be used to balance or aggregate the load on any number of belts.

The simplest website (factory)

Let’s start by looking at the simplest possible website and/or factory and build upwards from there. It looks like this:

Just one single service: a machine that takes input and produces output. If you have a personal website and you aren’t famous, it probably looks just like this: one service on one machine. The only reason you get away with it is because your request volume is low. What do we do when request volume gets too high for our one machine to handle?

Pools of machines

If one machine can’t handle your request volume, you obviously need more machines. But all the inputs are still coming in from one source, looking for something like medium.com. To solve this problem we add a new kind of machine, a load balancer, that distributes the request volume between more than one machine:

If you’re a Satisfactory player but not a programmer, you might be looking at this picture thinking, “why does the output go through the LB as well? What if I want multiple outputs?” Well, when designing a large system it’s very important to make things as simple to think about as possible. By limiting our pool to a single input and output, we can easily reason about our factory’s state compared to other machines. In fact, we don’t even need to know how many machines are in there! We can draw it like this instead:

Designing our site like this allows us to scale the number of machines inside the pool to a much higher number, as we’re limited by the throughput of the load balancer instead of an individual machine. Now when you suddenly become famous, you can add more machines behind your website’s load balancer and your site won’t crash!

Microservices

At some point just doing one thing isn’t enough, and your system’s responsibilities start to grow. This happens in Satisfactory when you need to build a component out of two other created components, and in web development when you introduce a fancy-but-too-popular feature. To handle this case, we build a completely new pool of machines:

Alternately, for a website:

This design is straightforward, but what about when two pools both depend on one other pool? What can we do to make it simpler?

Service communication options

When it comes to communicating between services there are three main approaches.

Direct calls. The easiest to implement and the hardest to think about. Each pool is connected directly to what it needs. In Satisfactory, this will make your factory look like spaghetti. API gateway. One area of the system is dedicated to routing requests to every pool in the system. This causes a clean separation with easy maintenance, but isn’t directly applicable to Satisfactory as the game is less request-based and more read-only. Message passing. Like spies, some services leave messages in a predetermined location and other services pick them up. The originating service doesn’t need to know where the resources are going.

In web development, the main trade-off between an API gateway and a message bus is that the gateway is synchronous (responds immediately) and the message bus is asynchronous (responds after unknown time). Satisfactory isn’t concerned with response time (only throughput), so let’s dive into the message passing approach!

Let’s build a message bus

Our message bus is going to be very simple: a whole lot of belts and storage space. Each pool will read only what it wants from the bus and then write its output back onto the bus.

Remember earlier, when I said that pools were limited by the throughput of their load balancers? That’s still true, but now that we have a bus, it’s easy to build a second pool! We can add as many pools to this bus as we want and never have to worry about which services depend on which other ones. We’re now only limited by the throughput of the bus itself, which in Satisfactory at least is quite easy and cheap to expand.

The glaring difference here is the output: on a website, you wouldn’t connect your bus directly to the outside world. Instead, you’d have a friendly access point that would pretty the output up for users a bit.

Improving performance for users

A website needs to serve its pages to users all over the world. As a factory builder in Satisfactory, you often need to construct outposts far away from your main base. Walking all the way back to base to get building materials is slow, which is why we invented content delivery networks, or CDNs.

By Kanoha — Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=7868809

When a user hits a page on your website, a CDN will record the response and cache it on a server that’s geographically close to that user. The next time the user returns, the page is loaded from the far-faster CDN instead. If a malicious user tries to DDoS your website or somebody needs 4000 concrete for some reason, a CDN will protect your main website from crashing.

To implement this in Satisfactory we can use storage containers, placed around the world in easy-to-reach locations just like CDN servers would be. These can be linked directly into our bus and will fill up without us having to worry about where the resources are coming from.

Wrap-up

If you’re a non-programmer and got this far, I hope you learned something! Many resources are available online to become a self-taught web developer, if you have the interest.

If you haven’t played Satisfactory or other factory-building games, I recommend giving the genre a try! It’s a lot of fun. What I’ve written here is only the tip of the iceberg.