Grids are Dead – or are they?

Huge datasets – not enough computing power. What to do? Don’t worry! The supercomputer concept Grid Computing is here to save you!

With the rise of cloud computing, fewer companies decide upon using Grid Computing – and even less know what the latter really is or how it can be used. What’s behind this matter? Is Grid Computing really dead? Let’s take a closer look.

Why did superman choose Grid Computing? Because he can save the world in parallel!

What is Grid Computing?

Grid Computing describes a network of decentral, distributed computers working together on a specific task. Instead of computing a task that would be rather difficult for a single machine, the computers combine their forces. This means, despite having different geographic locations, they work like a virtual supercomputer. The computers thereby contribute resources, such as processing power, memory and storage capacity, along the network. [1]

Because the virtual supercomputer is generated out of a cluster of coupled computers, Grid Computing is known as a subset of distributed computing. Developed to solve computationally intensive operations, it can be considered the Kryptonite of distributed computing. [1,2]

Meme of Grid as superman, saying it's saving you from complex computational operations.
Picture 1 | Supergrid

Why is it called Grid? Well, just like with electricity, the power comes “out of the socket”. By simply plugging the computer into the power grid, the computing starts. [1,3]

Foster and Kesselman postulate the following definition for Grid Computing:

A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational capabilities.

Is the architecture… a grid?

The Grid Computing Network generally consists of three types of computers, the so-called Nodes [1]:

  1. Control Node: Computer (Server / Group of Servers) which administers the whole network and keeps account of the resources in the network pool
  2. Provider Node: Computer which provides its resources to the network resource pool
  3. User Node: Computer which uses the resources of the network

These nodes have designated positions in a simple hierarchy, beginning with the (a) applications, then the (b) Middleware, the (c) available resources and the (d) computer itself that connects to the grid. Here’s a simple overview:

Graphic showing how Grid Computing works
Picture 2 | Grid Computing Architecture, adapted from [3]

The machines are connected via Ethernet or Internet. Instead of using a lot of CPU cores of one computer, the grid contains multiple cores that are spread across various locations in a large or even world-wide network. For controlling the network and its resources, a Middleware protocol is needed. This is mostly an open, standardized protocol connecting the grid’s resources with high-level-applications. The Control Node is the executor of the Middleware. [3,4]

The nodes may consist of machines using the same operating system, transforming the computer collective into a homogeneous network. If the nodes use different operating systems in a single grid computing network, they are called heterogeneous networks. The fact that they are allowed to use different OS, is one of the advantages and distinguishing parts of grid computing, in comparison to other distributed computing architectures. The virtualization of a single-system image – also called virtual organization – granting users and applications seamless access to IT capabilities is a very powerful feature. [1,3]

From Grid to Grid Computing

Contributing computing power to a Grid is relatively simple. A loosely-coupled computer makes a request to the control node. Then the Control Node gives the user access to the resources available. Whenever the computer is not in direct use, it contributes its resources to the network. The computers therefore are in constant balance / switching between being a user or a provider, based on their needs. [1,3]

Grid Computing shows the clustered and balanced lifestyle by living, laughing and computing in harmony.

Being the control node is not that easy. Since it is responsible for administering the network and making sure a provider is not overloaded with tasks. The provider gives permission to the user to run anything on its computer, which is a potential security risk for the whole network. This is why another important aspect is to authorize any process or task which is being executed on the network. [1,2]

Grid Infrastructure, showing many connected computers
Picture 3 | Grid Infrastructure, adapted from [6]

When the task is assigned, it gets broken into different subtasks. They are then divided and sent to different machines of the grid. After being solved, the results are sent back to the control node. The complete infrastructure shows the grid where computers interact with each other to coordinate the solving of a complex task. [2,6]

Depending on the use-case and the connected resource, one can differentiate between five different types of grid computing [3-5]: 

  • Computing Grids: Provide distributed computing resources to solve complex applications as a high-performance computer 
  • Data Grids: Shared usage of distributed data, provide storage capacity
  • Knowledge Grids: Scanning, connecting, collecting and analyzing big datasets
  • Resource Grids: Role-defined provider of data, software and hardware
  • Service Grids: Provide complete services and computing power to users

Grid vs. Cloud Computing

The idea of consuming computing power – like electricity is consumed from a power grid – is similar to what we nowadays know as Infrastructure-as-as-Service (IaaS) of Cloud Computing, where only these resources are used that a system currently needs. So, are Cloud and Grid Computing the same thing? [5,6]

Comparison of Grid and Cloud Computing Infrastructue
Picture 4 | Comparison of Grid vs. Cloud Computing Infrastructure, adapted from [5]

In a nutshell: No, they are not the same. They both are similar in that they contribute resources, make interactions between machines possible and provide resources. Hence, they use the concept of using the power of other entities to increase efficiency.

One difference lies in the segmentation of tasks. Grid Computing maximizes the available resources by splitting tasks into several different subtasks and computes them via different machines. No physical data center is needed. Cloud Computing, on the other hand, usually does have a physical data center, thus offering a homogeneous network.Another difference lies in their uniformity. Grid Computing allocates resources in its network to the related subtasks through decentralized coupling of computers. The Grid Provider thereby owns and organizes the infrastructure as a virtual supercomputer, while Cloud Providers organize the computing centrally and uniformly in the Cloud. [5,6]

‌History-Time: Popularity of Grid Computing

Let’s take a trip down memory lane: While doing some research on this topic, I came across many recent articles which state that grid computing allegedly is dead. Just like Cloud Computing nowadays, the Grid was predicted to be the state-of-the-art of computing infrastructures in the early 2000s. In an article from 1999 called “The Grid: Blueprint for a new computing infrastructure”, the idea of Grid Computing originally was first proposed as a concept by Ian Foster and Carl Kesselman. [1,7]

Businesses in biotech, the sciences and financial services have discovered that grids are competitive necessities.

NetworkWorld, 2006 [8]

In 2006, Network World USA stated that “this is the year that grid computing will move into mainstream” [8]. The main advantage of fewer costs for highly computational supercomputers spiked a lot of interest. But contrary to what was expected, Grid Computing did not reach mainstream status. It is a fact: the Grid is getting older and we have an enormous cloud guiding us to a phenomenal future. Why would we settle for anything less? [4]

The meaning of Grid Computing has changed over the years. The former distributed computing infrastructure has morphed into a distributed collaborative network. It now has a much more scientific approach towards solving mathematical, analytical and physics problems in research dealing with Big Data. Years later, mainly research institutes and some brave businesses apply Grid Computing. [5]

But not everyone has replaced Grid Computing yet.

When Grid Computing goes of the grid

Every desktop computer can be used to add power to the grid. This is why “normal” people can contribute as well. Common applications of grid computing are to be found in the sector of financial services (risk assessment), gaming (splitting tasks), entertainment (VFX), science and engineering. Computing and Data Grids are very commonly used in scientific projects (like genome sequence analysis during the Covid-19 pandemic), which inspire and motivate people to be part of a public collaboration across companies and networks. This is why Grid Computing falls into the category of peer-to-peer computing. [2,6]

The European Grid Infrastructure (EGI), the SETI@home (Search for Extraterrestrial Intelligence) by the University of Berkeley, the Scandinavian NorduGrid and the neuGRID (research on neurodegenerative diseases) are some famous examples of scientific projects using Grid Computing. The field of e-Science projects (scientific research collaborations for analysis) is certainly gaining popularity. This is especially interesting for natural sciences, medicine, meteorology, industry and particle physics – as further exemplified in the following section. [4,5,9]

A real life example: The Worldwide LHC Computing Grid (WLCG)

CERN – the European Organization for Nuclear Research – is most commonly known for physicists doing fundamental research on what the universe is made of. But it is less commonly known that this research involves computer scientists working with Grid Computing for data analysis.

CERN Accelerator Complex
Picture 5 | CERN Accelerator Complex [14]

The Large Hadron Collider (LHC) is currently the largest particle accelerator in the world. With a circumference of 27 kilometers, it investigates high-energy particle collisions through four main experiments: ALICE, ATLAS, CMS and LHCb. Stationed in Meyrin, Switzerland, particle physicists and computer scientists from all around the world collaborate together on something as special as fundamental research. [10,11]

Fun Fact: CERN is not only a huge cooperation, but the research around the building blocks of the universe (the quarks, antimatter and dark matter) provide inspiration for great science-fiction movies!

Simulation of Particle Collision (proton  - proton) at 13,6 TeV (Tera Electron Volts), as seen in the CMS detector during Run 3 at CERN
Picture 6 | Particle Collision (proton – proton) at 13.6 TeV as seen in the CMS detector during Run 3 at CERN [15]

The data produced by the CMS detector at the LHC is about 15 Petabyte per year. To show how much data that is to the common user, here are some comparisons [11,12]:

  • 1 PB is equivalent to over 4,000 digital photos for every day of your entire life. 
  • 1 PB is equivalent to 11,000 4k movies. It would take you over 2.5 years of nonstop binge watching to finish watching them.

The detector by those means can be seen as huge, high-resolution camera. You can now imagine just how enormous this dataset is. But enough background information… back to the Grid!

In order to be able to handle that huge amount of data produced by the LHC, CERN uses a Grid Infrastructure called the Worldwide LHC Computing Grid. In 2007, the WLCG was one of the first Grid Computing Infrastructures – and it is still in use today. CERNs mission is to provide global computing resources for the storage, distribution and analysis of the data generated by the LHC. It is a global collaboration of around 170 computing centers in more than 40 countries. They link up national and international grid infrastructures and analyze a dataset of around 200 Petabytes of data every year. CERN itself provides about 20% of the resources of the WLCG. [9,11]

Video | Close-to-real-time Visualization of the WLCG Grid Activity [15]

Individuals wishing to contribute with home computer resources can become involved in the LHC@home 2.0 project. Universities and Organisations can contribute as well. In order to access the LHC Grid, one must be registered as a Virtual Organization. Extensive information can be found on their website. [11]

Pros & Cons

Let’s recap all the Pro’s and Con’s of Grid Computing. [1,5]

Advantages of Grid Computing

  • Hardware-Independence: The concept of heterogeneous machines allows for different operating systems to be used in a single grid computing network. The coordination and management of cross-device processes and tasks is facilitated, as well as collaboration across networks possible.
  • Increased Efficiency: Through the physically distributed computer networks, parallel processing and analysis of huge amounts of data is possible.
  • Cost-effective Scaling of Processes: Using coupled computing power and storage capacities, complex tasks can be solved faster and more effectively.
  • Less Hardware-Costs: Through using the unused capacities of computers, no large investments in server infrastructure is needed. The users don’t have to pay for the resources and therefore save hardware costs.
  • Decentral and Flexible: Because there are no central servers required (except for the control node used for controlling), it is possible for computers to be located anywhere. Hence they have low failure rates, as capacities are distributed flexibly and modularly in the grid.
  • Easy Distribution: Reliable utilization and optimal use of IT infrastructure through virtual organizations and flexible task distribution is guaranteed.

Disadvantages of Grid Computing

  • Complex administration: The grid is unique for every project and system being used. There must be an agreement on which protocols are in use, to improve security.
  • Willingness to share resources: Through high energy costs and other circumstances, users might prefer to just plug out their computer, instead of leaving it running all night long. Therefore, creating the actual grid is difficult.
  • Non-Linearity: Computing power does not increase linearly with the number of coupled computers. At the same time there is less control over outages. This makes the behavior of the Grid unpredictable.

Conclusion: Is Grid Computing dead?

Yes and no. The answer to this question is not as easy as it seemed at first glance. Grid Computing no longer gets the attention it used to get. But that doesn’t mean it’s dead. It is still very much affordable and adequate for usage in highly computational processes concerned with Big Data. 

Because cloud computing is receiving more and more recognition with reliable and fast systems, plus virtualisation put into concepts, this might be the death of Grid Computing. But the existence of Grid Computing Infrastructures like the LHC Grid or other e-Science projects, with lots of people wanting to share their resources, is pretty unstoppable – for now.

Experiments being done with – for instance – particle accelerators are one-of-a-kind. They are special use-cases for which libraries or Middleware do not serve as resources. The concept of Grid Computing isn’t suitable for all software solutions, but it definitely isn’t dead to science and engineering.


[1] “Grid Computing.” GeeksforGeeks. (accessed Feb. 13, 2023).

[2] “What is grid computing? – Grid-Computing explained.” Amazon Web Services, Inc. (accessed Feb. 13, 2023).

[3] “What Is Grid Computing? Key Components, Types, and Applications,” Spiceworks. (accessed Feb. 13, 2023).

[4] N. Litzel and S. Luber, “Was ist Grid Computing?,” (accessed Feb. 21, 2023).

[5]  “Was ist Grid Computing?” IONOS Digital Guide.,Auslastung%20der%20Infrastruktur%20zu%20optimieren (accessed Feb. 13, 2023).

[6] J. Bausch. “Cloud computing vs grid computing.” Electronics Products. (accessed Feb. 15, 2023).

[7] I. Foster and C. Kesselman, The grid : blueprint for a new computing infrastructure. San Francisco, Calif.: Morgan Kaufmann ; Oxford, 2003.

[8] J. Bort. “Grid computing comes of age.” Network World. (accessed Feb. 15, 2023).

[9] F. Bry, W. E. Nagel & M. Schroeder, “Grid-Computing,” Informatik-Spektrum, Vol. 27, No.6, pp. 542–545, Dec. 2004, doi:

[10]  “The Worldwide LHC Computing Grid (WLCG).” CERN. (accessed Feb. 20, 2023).

[11] “Welcome to the worldwide LHC computing grid.” WLCG. (accessed Feb. 15, 2023).

[12]  T. Fisher. “Terabytes, Gigabytes, & Petabytes: How Big Are They?” Lifewire. (accessed Feb. 20, 2023).

[13] Autoren der Wikimedia-Projekte. “LHC computing grid – wikipedia.” Wikipedia – Die freie Enzyklopädie. (accessed Feb. 15, 2023).

[14] “The CERN accelerator complex”. CDS Photos · CERN. (accessed Feb. 15, 2023).

[15] “The Worldwide LHC Computing Grid activity captured live by the EGL application in August 2017.” CDS Videos · CERN. (accessed Feb. 15, 2023).

[16] “Shifting Perspectives of Grid Structure #1, Configuration #2.” Process by Alois Kronschlaeger. (accessed Feb. 15, 2023). 

[17] “Imgflip – Create and Share Awesome Images.” Imgflip. (accessed Feb. 15, 2023).


  • Picture 1 | Supergrid, designed with [17]
  • Picture 2 | Grid Computing Architecture, adapted from [3]
  • Picture 3 | Grid Infrastructure, adapted from [6]
  • Picture 4 | Comparison of Grid vs. Cloud Computing Infrastructure, adapted from [5]
  • Picture 5 | CERN Accelerator Complex [14] 
  • Picture 6 | Particle Collision (proton – proton) at 13.6 TeV as seen in the CMS detector during Run 3 at CERN [15]
  • Title Picture | Colorful Grid Structure [16]

Evaluating Cloud Gaming Services: Uncovering Key Quality Factors with Engaging Examples

Cloud Gaming, Source: Ajjan (2019)


Cloud gaming services have gained significant traction in recent years. They allow users to play high-quality games without needing powerful hardware. This technology revolutionizes the gaming industry by enabling gamers to stream games on-demand, regardless of their device’s capabilities. One key benefit of cloud gaming is that it eliminates the need for downloading and installing games or upgrading hardware. Players can access a vast library of games instantly and stream them in high quality without worrying about device limitations. Additionally, cloud gaming services offer flexibility, allowing players to pick up and play from where they left off on any device.

As a relatively new technology, cloud gaming enables gamers to stream games over the internet rather than playing them locally on a console or PC. In this setup, the game runs on a remote server, with video and audio output streamed to the player’s device. This system allows players to enjoy games on various devices, including smartphones, tablets, and low-powered laptops, without investing in expensive gaming hardware.

However, the quality of a cloud gaming service can vary depending on factors such as network latency, server capacity, game optimization, and more. In this blog post, we’ll explore what cloud gaming quality means and how understanding these factors can help gamers make informed decisions about selecting cloud gaming providers.

Technical overview

Abstract Cloud Gaming Architecture, Source: Cai et al. (2016)

A Cloud Gaming Architecture is the underlying framework that essentially enables the delivery of video games through streaming from remote servers to the users’ device.

The general, high level Cloud Gaming architecture consists of game servers that render and process games, encoding and streaming systems to deliver the content, Content Delivery Network for efficient content distribution, client devices for decoding and displaying the game, and adaptive streaming mechanisms to ensure a smooth gaming experience. I will give a brief description of these components.

Game Servers

These servers are the core of the cloud gaming architecture, responsible for running and rendering game instances. high-performance servers equipped with powerful CPUs, GPUs, and ample memory to run and render multiple game instances simultaneously. These servers are typically hosted in geographically distributed data centers, ensuring low latency and efficient resource allocation for users worldwide. Virtualization technologies, such as containerization or hypervisors, are used to run multiple game instances on a single server, optimizing hardware utilization with great success (Kämäräinen et al., 2015). Game servers may be hosted in data centers strategically located around the world to minimize latency and ensure a smooth gaming experience for users

Game Streaming and Encoding

Once a game is rendered on the game server, it must be encoded into a video format suitable for streaming. This involves converting raw video frames into a compressed format using video codecs, such as H.264, VP9, or H.265/HEVC. These codecs employ various techniques, including motion estimation, motion compensation, and transform coding, to achieve high compression efficiency while maintaining acceptable video quality. Adaptive bitrate streaming (ABR) algorithms, such as DASH or HLS, are used to dynamically adjust the video quality based on network conditions and device capabilities. The encoded video is then sent to the user’s device over the internet.

Data Transfer and Protocols

The encoded video stream is transmitted to the user’s device, the thin client, over the internet using streaming protocols, such as RTP (Real-time Transport Protocol), RTSP (Real-time Streaming Protocol), or WebRTC. These protocols handle packetization, synchronization, and error recovery, ensuring reliable and real-time delivery of video data. Adaptive bitrate streaming algorithms like DASH or HLS are used to adjust the video quality based on network conditions and device capabilities, ensuring a smooth gaming experience.In addition, cloud gaming platforms often use custom transport protocols, such as Google’s QUIC or NVIDIA’s NVFBC, to further optimize latency and throughput.

Content Delivery Network (CDN)

To minimize latency and ensure optimal performance, cloud gaming platforms typically rely on a Content Delivery Network (CDN). CDNs are networks of interconnected servers that cache and distribute content to users from the server closest to their location. CDNs consist of interconnected servers that cache and distribute content to users from the server closest to their location. This reduces the distance data must travel and minimizes the risk of network congestion. Popular CDN providers, such as Akamai, Cloudflare, or Amazon CloudFront, are used by cloud gaming platforms to enhance performance and scalability. This helps to reduce the distance data must travel and minimize the risk of network congestion, resulting in a smoother and more responsive gaming experience.

Client Devices and Decoding

Users can access cloud gaming services on various devices, such as PCs, smartphones, tablets, or even smart TVs. These devices must be equipped with the necessary software to decode the incoming video stream and display the game on the screen. Modern GPUs, such as NVIDIA’s Tegra or Qualcomm’s Adreno, are often used for hardware-accelerated decoding, reducing power consumption and latency. Software decoding is also possible, but may result in higher CPU usage and increased latency. Decoding involves converting the compressed video stream back into raw video frames that can be rendered by the device’s display.

Input Handling

In cloud gaming, user inputs (such as controller, keyboard or mouse actions) must be transmitted back to the game server to control the game. This introduces additional latency, as inputs must travel from the user’s device to the game server before being processed. To minimize this latency, cloud gaming platforms employ various techniques, such as local input prediction, which predicts the outcome of user inputs on the client device before receiving confirmation from the server. Cloud gaming platforms aim to minimize this latency to ensure a responsive gaming experience comparable to playing games locally.

Adaptive Streaming and Quality Control

To provide a seamless gaming experience, cloud gaming architecture often employs adaptive streaming techniques. These techniques adjust the quality of the video stream in real-time based on the user’s internet connection, device capabilities, user preferences and so on. Machine learning algorithms, such as reinforcement learning or neural networks, can be employed to optimize bitrate selection, frame rate adaptation, and quality control. This ensures that the stream remains smooth and uninterrupted, even under less-than-ideal network conditions.

Breaking Down Cloud Gaming Quality

Essentially, all these components that that describe cloud gaming have one primary focus – transferring the video stream and user input data efficiently and with minimal latency.

Since Cloud Gaming service providers are usually businesses in a highly competitive and fast-paced market, its is vital to identify unique selling propositions for business success. From great importance is the ‚Quality’ of the product or service.

But what exactly is quality in a context of cloud gaming and what is the meaning of it? Quality in the context of cloud gaming can be closely associated with the concepts of Quality of Experience (QoE) (Laghari et. al 2020), which refers to the overall user satisfaction with a gaming service and Quality of Service (QoS) (Gupta & Dutta, 2015) which is defined by the reliability of the underlying network and infrastructure that supports the gaming service. QoS focuses on the ability of the system to deliver a consistent and high-quality gaming experience by managing and prioritizing network resources, such as bandwidth, latency, and packet loss.

Enhancing both QoS and QoE is crucial for delivering a high-quality cloud gaming experience. To optimize QoS, cloud gaming providers can implement various strategies, such as traffic shaping, prioritizing gaming traffic, or using CDNs to minimize latency and improve network performance (Gupta & Dutta, 2019). On the other hand, improving QoE involves addressing user-specific requirements, such as adaptive video streaming (Laghari et al., 2020), optimizing game settings based on device capabilities (Cai et al., 2016), and improving input handling techniques to minimize latency and enhance responsiveness (Jarschel et al., 2011). QoS is measured objectively by collecting and evaluating data e.g. network performance etc. while QoE is subjectively by gathering data through surveys from users about their gaming experience. In essence, one can say QoS is more on the technical side of Cloud Gaming while QoE focuses on the social aspect.

Both aspect must be considered and optimized together to ensure user satisfaction and maintain the competitiveness of cloud gaming services in the market.

By analyzing studies and literature, I want to find out the most significant quality factors for cloud gaming.

Quality factors

In the following I listed Important factors of quality in Cloud Gaming, differentiated between the classes of QoS and QoE. The order of sequence is not of importance and doesn’t indicate one quality factor being better than the other.

Quality of Service (QoS) factors:

  • Latency: The time it takes for data to travel between the client device and the cloud gaming server. Low latency and fast response times are crucial for a seamless cloud gaming experience. It directly impacts the player’s experience and immersion in the game (Baldovino, 2022)
  • Bandwidth: The amount of data that can be transmitted over the network per unit of time and the consistency and reliability of the network connection between the client device and the cloud gaming server. A stable network connection and sufficient bandwidth are crucial for uninterrupted cloud gaming. Network stability is important to prevent disconnections or lag, while bandwidth ensures high-quality streaming (Cai et al., 2016b).
  • Packet loss: The percentage of data packets that are lost during transmission over the network. Packet loss can lead to video and audio glitches, as well as disruptions in gameplay. High packet loss can make the gaming experience frustrating for users, as they may miss critical in-game moments or experience inconsistent game performance. Minimizing packet loss is essential for maintaining a stable and seamless gaming experience (Möller et al., 2018).
  • Jitter: It refers to the variation in latency over time. High jitter can cause gameplay to be uneven or stutter, which can be particularly disruptive in fast-paced games. Low jitter ensures consistent and smooth gameplay, enhancing the overall gaming experience (Huang et al., 2014).
  • Network stability & Server Performance: A stable network connection ensures that the cloud gaming service can maintain a consistent and reliable data stream between the client device and the cloud gaming server. Network instability can lead to interruptions in gameplay or poor performance, negatively affecting the user experience. Efficient server performance is critical for processing and rendering game content in real-time. Poor server performance can result in slow loading times, low frame rates, or gameplay glitches. High-performance servers ensure a smooth and responsive gaming experience for users (Shea et al., 2015; Shea et al., 2013).

Quality of Experience (QoE) factors:

  • Video quality & Frame rate: The visual clarity and sharpness of the game video stream as experienced by the user. Video quality and frame rate are essential for a visually appealing and immersive gaming experience. High video quality with a consistent frame rate ensures that the gameplay appears smooth, while low video quality or inconsistent frame rates can lead to a less enjoyable experience for the user (Lin & Shen, 2018).
  • Responsiveness: It is the measure of how quickly the game reacts to user inputs, such as button presses or mouse movements. In cloud gaming, a highly responsive game allows users to feel more in control and engaged, while poor responsiveness can lead to frustration and decreased enjoyment (Chuah et al., 2014).
  • Device compatibility: The ability of the cloud gaming service to work seamlessly with various client devices, such as smartphones, tablets, or PCs. Support for various input devices, such as game controllers, keyboards, and mice, is essential for a versatile and accessible cloud gaming experience (Laghari et al., 2020).
  • Audio quality: High-quality audio is vital for an immersive gaming experience, as it can enhance the game’s atmosphere and provide important audio cues to the player. Poor audio quality or audio synchronization issues can negatively impact the player’s engagement and overall gaming experience (Wen & Hsiao, 2014).
  • Content availability: The selection and variety of games available on the cloud gaming platform. A diverse game library and support for multiple platforms, including PCs, consoles, and mobile devices, make the cloud gaming service more appealing to a broader audience (Möller et al., 2018, Biradar & Nagoor, 2017).
  • Pricing & Business Model: The pricing structure and business model of a cloud gaming service can significantly influence the user’s perception of value and overall satisfaction. Affordable pricing plans and flexible subscription options can make cloud gaming services more accessible and appealing to users, while overly expensive or restrictive plans may deter potential customers (Gupta & Dutta, 2019).
  • Customer Support and Reliability: Reliable customer support is important to ensure users can quickly resolve any issues they may encounter while using a cloud gaming service. Effective customer support and service reliability can increase user trust and satisfaction, while inadequate support can lead to frustration and dissatisfaction (Laghari et al., 2020).
  • User interface and usability: A user-friendly interface and intuitive controls can significantly enhance the overall Quality of Experience in cloud gaming. An easy-to-navigate system helps users quickly find and access the games they want to play, while a complicated interface can be frustrating and deter users from fully utilizing the service (Cai et al., 2016).

Essentially and speaking in a highly simplified manner, It all breaks down to a User Experience combined with technical implementation. It is from most utter most importance, to optimize these pieces of the Cloud Gaming Service.

Example: Assessing the of quality of controversial Cloud Gaming services

Now that we have identified essential factors for Cloud Gaming services, let’s evaluate a few. I decided to assess presumably controversial or discontinued services for several reasons: to learn from failures, to hypothesize the success of one Cloud Gaming service based on the identified quality factors, and to avoid providing free advertisement.

Google Stadia

Google Stadia Controller, Source: Pinto (2020)

Google Stadia, a Cloud Gaming Service by Google LLC, launched in November 2019, promising instant 4K, 60 FPS gameplay streamed through a screen of choice. However, it failed to deliver on its promise, wasn’t profitable for Google LLC, and shut down in January 2023. What happened?

I identified key reasons for Google Stadia’s failure concerning the quality factors, which are described below.

1 – Platform & Perfomance

imited device compatibility was a significant issue for Google Stadia during its initial launch. Stadia’s cloud gaming service relied on specific hardware and software requirements to enable streaming and input handling, which initially limited the number of supported devices.

Initially, Stadia was only compatible with a limited number of devices, including Google’s Pixel smartphones, Chromecast Ultra, and desktops with Google Chrome browser support. This restricted access to the platform and made it less appealing to users with non-compatible devices. Several technical reasons limited the platform’s compatibility:

  • Video Codec Support: Stadia used the VP9 video codec for video streaming, which offers better compression efficiency compared to other codecs like H.264. However, not all devices supported the VP9 codec, limiting the range of compatible devices (Warren, 2020).
  • Input Handling: Stadia required devices to support specific input handling protocols to ensure seamless communication between the gaming controller and the cloud gaming server. Some devices might not have had the necessary support for these protocols at launch (Ruben, 2019).
  • Hardware Performance: Stadia’s video streaming and decoding process required a certain level of hardware performance to ensure smooth gameplay. Devices with lower-performance hardware may have struggled to provide a satisfactory gaming experience, leading to initial compatibility restrictions (Warren, 2020).

Despite Google’s vast infrastructure, many users experienced latency and performance issues with Stadia, resulting in a suboptimal gaming experience, especially for fast-paced and competitive games. Google Stadia faced criticism for its latency issues, with some users reporting input lag of up to 100-200 milliseconds or more, highly detrimental to gameplay. High latency can be attributed to various factors, such as network congestion, server processing time, and the encoding/decoding process for streaming video content (TheKLF, 2022).

Stadia launched without several promised features, such as family sharing and 4K streaming on all devices. Stadia promised 4K resolution and HDR support at launch, but many users experienced video quality issues due to compression artifacts, resolution scaling, and inconsistent frame rates. These issues could be attributed to the video encoding process, where the balance between compression efficiency and visual quality is crucial to delivering an optimal gaming experience (Ruben, 2019).

Stadia’s high-bandwidth requirements (up to 35 Mbps for 4K streaming) meant that users with slower internet connections, data caps, or inconsistent network performance faced difficulties when attempting to use the service. This limitation restricted Stadia’s accessibility and adoption, as many potential users could not enjoy a seamless gaming experience due to their internet connection constraints (Hamilton, 2019).

This created a barrier to entry for potential users and made the platform less appealing to a wider audience.

2 – Pricing

When considering a Cloud Gaming/Streaming service, users often think of a subscription model. However, that wasn’t the case with Google Stadia. Stadia’s pricing model, which required users to purchase individual games in addition to a monthly subscription fee, was criticized for being less attractive than competitors’ offerings. Google Stadia offered two subscription models: A base tier with a few free-to-play games and a Pro tier for $10 a month, which included more free-to-play games and 4K gameplay on an irregular basis. This strategy proved unsuccessful in the case of Google Stadia.

3 – Game Selection

At the time of launch, Stadia’s game library was relatively small compared to established competitors such as Xbox Game Pass and PlayStation Now. This limited selection of games made it difficult for Stadia to attract new users and retain existing ones. Additionally, games purchased on Stadia were only accessible as long as the service existed, undermining the purpose of Cloud Gaming and an important quality factor: content availability and usability.

4 – Lack of support

Google Stadia faced criticism for its lack of features and support at launch, which contributed to its underwhelming reception. Many key features were missing or limited at launch, despite being promised during marketing campaigns, such as:

  • Achievements: Stadia did not launch with a fully functional achievements system, which is a standard feature on other gaming platforms. Achievements provide players with additional goals and rewards for completing specific in-game tasks, enhancing the gaming experience. This feature was eventually implemented, although it took some time (Google Stadia: How To See Achievements, 2021).
  • Family Sharing: At launch, Google Stadia lacked a family sharing feature, making it difficult for families with multiple users to share purchased games across their accounts. This absence limited the platform’s appeal to families and multi-user households (Bradshaw, 2020).
  • Wireless Controller Support: The Stadia controller initially required a wired connection to devices other than the Chromecast Ultra, limiting its usability and convenience. Full wireless support for other devices was added later (Bradshaw, 2020).
  • Stream Connect and State Share: Two of Stadia’s advertised features, Stream Connect and State Share, were not available at launch. Stream Connect enables local split-screen gaming via cloud gaming, while State Share allows players to share specific game states with others. The absence of these features reduced the platform’s appeal and the potential for unique gaming experiences (Bradshaw, 2020).
  • Social Features: Stadia lacked robust social features like integrated voice chat, messaging, and friend list management at launch, limiting the platform’s ability to foster a gaming community (Hollister, 2019).


The failure of Google Stadia was inevitable. In conclusion, Google Stadia was a bold attempt by Google to enter the cloud gaming market with the promise of delivering high-quality gaming experiences on a wide variety of devices. However, several factors contributed to the platform’s failure. Key issues included limited device compatibility, latency and performance issues, an unappealing pricing model, a limited game library, and a lack of features and support at launch. These shortcomings hindered Stadia’s ability to compete with established gaming platforms and attract a broad user base, ultimately leading to its discontinuation.

Despite its ambitious vision, Google Stadia’s inability to deliver on its promises and meet user expectations in terms of quality factors such as QoS and QoE resulted in a lackluster reception and adoption rate. The lessons learned from Google Stadia’s failure can serve as valuable insights for the development and improvement of future cloud gaming platforms, emphasizing the importance of addressing both technical and user experience aspects to ensure success in this competitive market. Google LLC also does have a history of discontinuing services, so this doesn’t come as a surprise.

Netflix Games

Netflix Games library, Source: Spangler (2021)

Netflix Inc. itself has faced significant problems in the last year, losing almost 1.2 million customers, experiencing a stock collapse, and dealing with strong competition. To counter the market’s growing competition and remain competitive, Netflix decided to expand its business to include streaming games with its new service: Netflix Games. Unfortunately, Netflix Games doesn’t deliver on its promises for consumers and for the company. Why is that?

Netflix Games is available in the basic Netflix subscription and thus, doesn’t require additional costs for customers. With already over 230 million users (Statista, 2023), Netflix offers additional content to its user base, without building a separate complex gaming platform or selling another subscription. It seems like a smart business decision to expand its portfolio, retain existing customers, and potentially acquire new ones. However, this strategy doesn’t translate well to Netflix Games, as the service only has 1.7 million daily average users, which is relatively low compared to Netflix’s existing user base (Stebbins, 2022). I identified the following problems.

1 – Platform:

Netflix Games is only available through the Netflix app on smartphones or tablets. As a result, only 10% and 5% of users stream via smartphones and tablets, respectively. The biggest share belongs to TV with 70% (TrueList, 2023). This means Netflix misses out on over 70% of its existing user base, making effective marketing impossible. This is supported by a survey from 2022 that shows only 17% of the interviewed individuals had heard of Netflix Games (Shevenock & Shevenock, 2022). A key quality factor for cloud gaming is seamless accessibility on and through various thin clients. Netflix Games fails in this regard.

2 – Game selection

Netflix has trademark rights to many great series, making them exclusive to their platform. This exclusivity is one of the main reasons for Netflix’s success. Netflix Games offers a meager selection of about 40 games. This number is relatively low, but the bigger issue is that games offered by Netflix are mostly considered time killers for in-between moments rather than AAA titles. This is an important quality factor for cloud gaming users that can’t be satisfied. This limitation can be attributed to the fact that Netflix is typically not in the business of content creation but content distribution. To compete with cloud gaming providers that offer AAA gaming titles, Netflix would need to make a significant move in the gaming industry, such as acquiring a popular gaming studio.


In conclusion, Netflix Games was an ambitious attempt by Netflix to diversify its offerings and expand into the gaming industry. Despite the potential to leverage its massive user base, the service has struggled to gain traction due to limitations in platform accessibility and a lackluster game selection. By restricting the service to smartphones and tablets, Netflix inadvertently excluded a significant portion of its audience, resulting in ineffective marketing and low adoption rates. Furthermore, the absence of AAA titles and a focus on casual time-killer games fail to deliver the quality and depth that cloud gaming users expect.

The challenges faced by Netflix Games highlight the importance of addressing critical quality factors in cloud gaming, such as platform compatibility and content quality. To succeed in this competitive market, companies venturing into cloud gaming must ensure seamless access across various devices and deliver a compelling gaming experience that caters to the diverse needs of users. Future endeavors in the cloud gaming space can learn from the shortcomings of Netflix Games and take necessary steps to create a more inclusive and engaging experience for users. Until Netflix Games improves in these areas, this service is more of a side gig than a truly value-adding feature for Netflix.

Final Remark

To sum it all up, cloud gaming has the power to transform the gaming world by making high-quality gaming experiences more accessible and user-friendly. But to make a real splash in this competitive space, cloud gaming providers need to pay close attention to the crucial factors that determine the Quality of Service (QoS) and Quality of Experience (QoE).

Focusing on low latency, ample bandwidth, minimal packet loss, and a rock-solid network connection will ensure that gamers have a smooth and enjoyable time. On top of that, paying attention to video and audio quality, quick responsiveness, compatibility across devices, a diverse range of games, reasonable pricing, and top-notch customer support will make users even happier.

Cloud Gaming is still a niche of the incredibly enormous gaming market. For cloud gaming services to thrive, it’s important to keep an eye on these factors and adapt to the ever-changing needs of gamers. By learning from past mistakes and successes, cloud gaming can continue to push boundaries and offer amazing gaming experiences to more and more people.


  • Ajjan, M. (2019, 29. September). 스페이스 그레이 아이폰. Unsplash. uOOBQhUs1AA
  • Amiri, M., Osman, H. A., Shirmohammadi, S. & Abdallah, M. (2016). Toward Delay-Efficient Game- Aware Data Centers for Cloud Gaming. ACM Transactions on Multimedia Computing, Communications, and Applications, 12(5s), 1–19.
  • Baldovino, B. (2022). An Overview of the Networking Issues of Cloud Gaming. Journal of Innovation Information Technology and Application, 4(2), 120–132.
  • Biradar, S. & Nagoor, N. (2017). A Review on Cloud Gaming. nternational journal of advanced research in computer and communication engineering6(5), 92–95. ijarcce.2017.6518
  • Bradshaw, K. (2020, 20. November). Review: One year later, Google Stadia is still a diamond in the rough. 9to5Google. diamond-rough/
  • Cai, W., Shea, R., Huang, C., Chen, K., Liu, J., Leung, V. C. M. & Hsu, C. (2016a). A Survey on Cloud Gaming: Future of Computer Games. IEEE Access, 4, 7605–7620. access.2016.2590500
  • Cai, W., Shea, R., Huang, C., Chen, K., Liu, J., Leung, V. C. M. & Hsu, C. (2016b). A Survey on Cloud Gaming: Future of Computer Games. IEEE Access, 4, 7605–7620. access.2016.2590500
  • Chuah, S., Yuen, C. & Cheung, N. (2014). Cloud gaming: a green solution to massive multiplayer online games. IEEE Wireless Communications, 21(4), 78–87. mwc.2014.6882299
  • Google Stadia: How To See Achievements. (2021, 5. April). [Video]. Abgerufen am 1. Mai 2023, von
  • Hamilton, E. (2019, 8. Juni). Google Stadia could slurp 1TB of data in 65 hours streaming at 4K. TechSpot. Abgerufen am 8. Mai 2023, von could-slurp-1tb-data-65-hours.html
  • Hollister, S. (2019, 18. November). Google Stadia review: the best of cloud gaming is still just a beta. The Verge. streaming-cloud-price-specs-features-chrome-pixel
  • Huang, C., Chen, K., Chen, D., Hsu, H. & Hsu, C. (2014). GamingAnywhere. ACM Transactions on Multimedia Computing, Communications, and Applications10(1s), 1–25. 10.1145/2537855
  • Kämäräinen, T., Shan, Y., Siekkinen, M. & Ylä-Jääski, A. (2015). Virtual machines vs. containers in cloud gaming systems. In 2015 International Workshop on Network and Systems Support for Games (NetGames).
  • Möller, S., Pommer, D., Beyer, J. & Rake-Revelant, J. (2013). Factors Influencing Gaming QoE: Lessons Learned from the Evaluation of Cloud Gaming Services. pqs.2013-31
  • Netflix: number of subscribers worldwide 2023 | Statista. (2023, 20. April). Statista. https://
  • Pinto, C. (2020, 28. März). Weiß Xbox One Gamecontroller. Unsplash. fotos/4P0zdOSstqI
  • Ruben, T. (2019, 25. März). Variety. Variety. Abgerufen am 8. Mai 2023, von gaming/opinion/google-stadia-is-a-net-neutrality-nightmare-1203170741/
  • Serrels, M. (2019, 18. November). Google Stadia adds 10 more games to its launch lineup. CNET.
  • Shea, R., Fu, D. & Liu, J. (2015). Cloud Gaming: Understanding the Support From Advanced Virtualization and Hardware. IEEE Transactions on Circuits and Systems for Video Technology, 25(12), 2026–2037.
  • Shea, R., Liu, J., Ngai, E. C. & Cui, Y. (2013). Cloud gaming: architecture and performance. IEEE Network, 27(4), 16–21.
  • Shevenock, S. & Shevenock, S. (2022). Are Influencers the Answer to Netflix’s Gaming Conundrum? Morning Consult.
  • Spangler, T. (2021, 9. November). Variety. Variety. games-apple-ios-launch-1235108196/
  • Stebbins, J. (2022, 8. August). Netflix is expanding its push into video games, but few subscribers are playing along. CNBC. subscribers-playing-along.html
  • TheKLF. (2022, 29. September). Google Stadia review. Tom’s Guide. Abgerufen am 8. Mai 2023, von
  • TrueList. (2023, 9. Januar). Netflix Statistics 2023 – TrueList. Abgerufen am 1. Mai 2023, von https://
  • Warren, T. (2020, 5. März). Google Stadia now supports 4K streaming on the web. The Verge. Abgerufen am 8. Mai 2023, von streaming-web-chrome-roll-out-release-date-features
  • Wen, Z. & Hsiao, H. (2014). QoE-driven performance analysis of cloud gaming services. https://

Von Studierenden für Studierende: Grundlagentutorium – Unterstützung & Empowerment

Kim Bastiaanse, Tamara Hezel


Die Idee zu unserem Projekt entstand aus einem Gespräch mit einer Studentin des 3. Semesters. Aufgrund von Wissenslücken und Unsicherheiten hatte sie überlegt, ihr Studium abzubrechen. Wir fühlten uns direkt in unsere ersten Semester im Studiengang Mobile Medien zurückversetzt und überlegten, was uns damals geholfen hätte.

Daraus entstand unsere Idee, einen fächerübergreifenden Einstieg in die Informatik in Form eines Tutoriums anzubieten. Ziel dabei war nicht die Verbesserung oder Vertiefung einer bestimmten Vorlesung, sondern vielmehr die Verdeutlichung von Zusammenhängen zwischen den Themen sowie die Erklärung grundlegender Buzzwords. Die Vorlesungen sollten in einen größeren Kontext eingebettet, deren praktische Relevanz aufgezeigt und aufkommende Fragen der Studierenden geklärt werden.

Neben der rein fachlichen Kompetenz war es uns ein besonderes Anliegen, den Studierenden die Welt der Informatik auf eine ansprechende und motivierende Art näherzubringen. Wir wollten die vielfältigen Möglichkeiten und Facetten dieses spannenden Feldes aufzeigen und dabei helfen, eventuelle Ängste oder Vorbehalte abzubauen. Auch dem von Professor Walter Kriha beobachteten “Rückzugseffekt”, der durch negative Gefühle der Studierenden entsteht, wollten wir entgegenwirken.

Neben dem Tutorium boten wir den Teilnehmerinnen eine offene Sprechstunde an, in der auch nicht-fachliche Themen besprochen werden konnten.

Unser Angebot richtete sich an “Informatik-Anfänger” des 1., 2. und 3. Semester Mobile Medien (MM) und Medieninformatik (MI).


Fragen zu stellen, sich freudig Neuem zu öffnen und auch mal ein Scheitern zu akzeptieren sind Eigenschaften, die nicht nur im Rahmen des Studiums wertvoll sind. Besonders in Bezug auf Softwareentwicklung und Informatik verlieren viele Studierende in den ersten Semestern schnell den Mut. Überforderung und Frustration, gepaart mit Ängsten, hindert eine bestimmte Gruppe daran, selbstbewusst in die Informatik einzusteigen. Die Unsicherheit wächst, Fragen bleiben ungestellt und die Hürde, vermeintlich einfache Dinge in der Vorlesung zu erfragen, steigt von Woche zu Woche. Besonders für Studienanfänger:innen ohne Vorwissen im Bereich der Informatik sind viele, vermeintlich einfache, Begriffe unbekannt und Zusammenhänge zwischen den Vorlesungsinhalten unklar.

Für genau diese Gruppe an Studierenden gibt es bisher kein passendes Angebot. Auch wenn vertiefende Tutorien und Übungen bereits einen wichtigen Beitrag leisten, gibt es aktuell keine Veranstaltung, die grundlegende Wissenslücken und Zusammenhänge abdeckt und Buzzwords themenübergreifend erklärt. Die Unterstützung von Studierenden diesbezüglich halten wir jedoch für sehr relevant und wegweisend für die akademische sowie berufliche Zukunft.

Unser Ziel war es daher, mit diesem Projekt einen sicheren Rahmen für Studierenden zu schaffen, in dem sie frei von Scham, Ängsten und Zurückhaltung handeln, ihre grundlegenden Wissenslücken schließen und damit zu Kommilitonen mit Vorwissen aufschließen können. Dabei ist es uns wichtig, den Studierenden zu zeigen, dass sie nicht alleine mit ihren Zweifeln und Unsicherheiten sind und ihr Selbstbewusstsein zu stärken.

Forschungsfrage und Hypothesen

Wie kann man Studierende motivieren, ihre Fragen offen und ehrlich zu stellen und ihre Unklarheiten anzusprechen? Wie kann man einen sicheren Rahmen schaffen und Inhalte so vermitteln, damit sie nachhaltig verstanden werden? Und welche spezifischen Themen müssen behandelt werden, um diese Wissenslücken zu schließen? Diese Fragen haben wir uns zu Beginn des Projekts gestellt und versucht mithilfe von theoretischer Recherche, qualitativen sowie quantitativen Methoden zu beantworten. Die Forschungsfrage: “Gibt es das Problem von einschränkenden, grundlegenden Wissenslücken bei Studierenden und wie könnte eine Unterstützung für betroffene Personen aussehen?”, spielte dabei jederzeit eine zentrale Rolle und deren Beantwortung floss direkt in die konkrete Umsetzung des Tutoriums ein. Um sich schrittweise den Antworten zu nähern, wurden verschiedene Hypothesen aufgestellt, die in zwei Phasen belegt oder widerlegt werden sollten. 

Es ergaben sich konkret folgende Hypothesen H1 – H4, die sich auf den aktuellen Wissensstand und die Situation der Studierenden im Studium beziehen. Sie werden im Umfang der ersten Studien überprüft. Dabei soll grundsätzlich herausgefunden werden, ob das Angebot eines Grundlagentutoriums von den Studierenden als notwendig und hilfreich empfunden wird, welche Thematiken in dessen Rahmen behandelt werden sollen als auch wie eine solche Umsetzung explizit aussehen könnte.

H1: Es wird erwartet, dass es grundlegende Wissenslücken bei Studierenden bzgl. den Grundlagen der Informatik gibt.

H2: Studierende, die ohne Vorwissen ins Studium gestartet sind, haben grundlegende Wissenslücken.

H3: Studierende fühlen sich durch ihre Wissenslücken abgehängt und haben negative Gefühle (z.B. Angst, Stress, Rückzug etc.).

H4: Es wird erwartet, dass ein zusätzliches Angebot von Studierenden, mit ähnlichen Erfahrungen, in Form eines Tutoriums als hilfreich eingestuft wird (und Personen teilnehmen würden).

Zur Validierung des Nutzens und der Reflektion des Grundlagentutoriums nach der Durchführung wurden die nachfolgenden Hypothesen H5 – H8 aufgestellt: 

H5: Studierende, die am Tutorium teilgenommen haben, fühlen sich sicherer mit den Buzzwords und den Zusammenhängen der Informatik.

H6: Studierende, die das Tutorium besucht haben, fühlen sich vom Kenntnisstand aufgeholt in Bezug zu den anderen Studierenden in ihrem Semester.

H7: Durch das Grundlagentutorium konnten grundlegende Wissenslücken für Studierende, die das Tutorium besucht haben, geschlossen werden.

H8: Es macht für die Studierenden einen Unterschied, ob solch ein Tutorium von Studierenden angeboten wird, die mit ihrer Lebensrealität näher an den Studienanfänger:innen sind oder von Dozenten mit viel Erfahrung.

Diese Hypothesen werden im zweiten Forschungsteil, nach der Durchführung durch eine Umfrage und persönliche Rückmeldungen der Studierenden validiert und dienen als Grundlage für Verbesserungen und für die Entscheidung zur Fortführung des Angebots.


Um einen möglichst hohen Lerneffekt bei den Studierenden zu erreichen, war es wichtig sich tiefgehende Gedanken zu folgenden Fragen zu machen:

–       Wie schafft man einen sicheren Raum?

–       Wie bekommt man die Studierenden dazu Fragen zu stellen?

In den nachfolgenden Teilen werden diese Fragen aufgegriffen und unsere Lösungsansätze dazu vorgestellt.


Um zu erfahren, ob unsere Idee von den Studierenden als notwendig erachtet wird, haben wir eine quantitative Studie mit 96 Studierenden des 1. – 3. Semesters der Studiengänge MMB und MI durchgeführt. Parallel dazu befragten wir Personen aus derselben Personengruppe in Form von Fokusgruppen und Interviews, um qualitative Ergebnisse zu sammeln. Darüber hinaus haben wir durch Experteninterviews die Meinungen von Prof. Walter Kriha, Dr. Tobias Jordine und Benjamin Binder einbezogen.

Mit den ausgewerteten Studienergebnissen konnten die Thementage konzipiert und das Tutorium geplant werden. Die ausgewählten Themen wurden aufbereitet und Skripte, Checkerfragen und Präsentationen zu den Inhalten erstellt. 

Während der Durchführungsphase wurden Tutorien zu den verschiedenen Themen abgehalten. Insgesamt wurden 12 Plätze an Studierende aus dem 1. – 3. Semester vergeben. Die Konzeptions- und Durchführungsphase wurden dabei häufig parallel bearbeitet.

Die zweite Recherchephase beinhaltet erneute qualitative und quantitative Umfragen nach Abschluss des Tutoriums. Dabei wurden die teilnehmenden Studierenden zur Durchführung befragt und Verbesserungsvorschläge sowie Ideen gesammelt.


Wenn man googelt, wie man Informatik lernt, ist die komplette erste Seite von Google voll damit, wie man programmieren lernt. Dabei steckt in der Informatik noch viel mehr:

Es geht darum, Probleme zu analysieren, Sachverhalte zu verstehen und effektive Lösungen zu finden. Die Informatik ist ein sehr breites und multidisziplinäres Feld, das sich mit vielen verschiedenen Aspekten der Technologie und des menschlichen Lebens befasst. Es ist wichtig, ein umfassendes Verständnis für die Konzepte und Grundprinzipien der Informatik zu entwickeln, um erfolgreich in diesem Bereich zu sein.

In der Literatur finden sich viele Ansätze zum Lernen von Informatik. So beschreibt Schwill die Brunerschen Prinzipien [1]. Das erste Prinzip, das genannt wird, ist die Fortsetzbarkeit. So sollte bereits bei der Auswahl des zu behandelnden Themas darauf geachtet werden, dass ein späterer Niveau-Ausbau möglich ist. Bei der Behandlung der Themen sollte zudem stets bedacht werden, dass keine Halbwahrheiten vermittelt werden, die ein Umdenken der Lernenden zu einem späteren Zeitpunktes benötigen [1]. Für unser Grundlagentutorium haben wir unsere Themen zwar selbst gewählt – diese sind jedoch eng mit den Vorlesungen, die angeboten werden, verknüpft. Dabei sind die Einzelthemen so konzipiert, dass auf die Fortsetzbarkeit geachtet wurde. Für unser Tutorium war es außerdem relevant, dass wir uns selbst so gut vorbereiten, dass wir keine Halbwahrheiten erzählen. Bei Unwissenheit sollte diese transparent gemacht und fehlendes Wissen zusammen mit den Studierenden nachrecherchiert werden.

Als zweites Prinzip führt er die Präfiguration von Begriffen auf. Damit ist gemeint, dass Bilder und Handlungen verwendet werden sollen, um Begriffe und Konzepte zu veranschaulichen und verständlich zu erklären. Anstatt die Syntax einer Programmiersprache oder ihrer Elemente direkt zu erklären, ist es besser, sie zunächst einfach praktisch anzuwenden – beispielsweise durch die Verwendung von Pseudocode [1]. Auch wir wollten viel mit Metaphern und Analogien arbeiten. Ein Beispiel dafür ist die Vorstellung des abstrakten Begriffes eines Servers als eine Art Raum: Es gibt Türen, die zum Frontend und zur Datenbank führen. Andere Türen dienen als Schnittstelle, um das Prinzip von APIs zu erklären. Für manche Türen ist eine Authentifizierung durch einen Token oder Passwort notwendig, um sie zu öffnen, Andere sind gar nicht “betretbar”.

Final kommt Schwill noch auf das Prinzip des vorwegnehmenden Lernens zu sprechen. Damit ist gemeint, dass es besser sei, ein Wissensgebiet schon auf früheren Stufen in einfacher Form zu behandeln, anstatt auf eine endgültige und abschließende Behandlung zu warten [1]. Da wir in unserem Tutorium Studierende des 1. bis 3. Semesters betreuen wollen, ist es unumgänglich, dass manche Studierende mit Teilen in Kontakt kommen, die sie noch nicht gehört haben oder noch nicht gänzlich verstehen. Dabei war es uns wichtig, die Studierenden auf einer hohen Flugebene abzuholen und ihnen die groben Konzepte zu verdeutlichen. Das komplette Verständnis kann dann nachfolgend in den vertiefenden Vorlesungen erfolgen. Dieser Ansatz hilft Ängste vor zu vielen Details, Starre vor Überforderung und die Flucht in das Konkrete vorzubeugen.

Da wir die Vermutung haben, dass die Studierenden, die unser Angebot besuchen, vor allem mit Ängsten und Selbstzweifeln zu kämpfen haben, haben wir uns auch mit Literatur zum Thema Leistungsdruck und Lernen beschäftigt. Schwarzbauer et al. [2] bestätigt, was wir auch schon selbst erlebt haben: Gelernt wird für den Erfolg in der Prüfung. Der eigene Fokus geht weg vom Interesse am Thema und die damit einhergehende intrinsische Motivation, sich mit diesem zu beschäftigen, und wandelt sich hin zu einer vorwiegend extrinsischen Motivation. Durch den Wunsch nach guten Noten verlieren betroffene Studierende häufig den Blick auf das große Ganze sowie dessen praktische Relevanz und vermeiden es Risiken einzugehen. Mögliche negative Gefühle, die durch die Verknüpfung mit Leistung entstanden sind, übertragen sich auf das Thema selbst. Es wird das fälschliche Gefühl geweckt, dass der Misserfolg im Rahmen des Studiums sich nur auf die eigenen Werte und Kenntnisse zurückführen lässt, was jeglichen neuen Mut und Selbstbewusstsein sowie Wachstum und Möglichkeiten in der Berufswelt vermeintlich versperrt.

Schwarzbauer führt zudem auf, dass der Lernerfolg stark unter Ängsten leidet. Gelerntes gerät schneller in Vergessenheit, die Angst verfestigt sich und wird immer wieder abgerufen. Diese Tatsache bestärkt das oben beschriebene Gefühl von Misserfolg und hält diese Studierende auf, sich an Neues zu wagen und selbstbewusst für sich und ihre Kenntnisse einzustehen. Die entstandene Verknüpfung von Leistungsdruck, Angst und Informatik ist schwer zu reflektieren und eigenständig aufzubrechen.

Leistungsabfragen müssen jedoch nicht immer negativ sein. Als positive Methoden werden in der Literatur beispielsweise kontinuierliches Feedback und Lerntipps aufgeführt [2]. Für uns war daher klar, dass unser Checkerfragen-Ansatz ein wichtiger Baustein für das Grundlagentutorium ist. Um den Studierenden kontinuierliches Feedback zu geben, gab es zu wenige Kontaktpunkte. Sie nach jeder Stunde allerdings noch einmal über Gehörtes reflektieren zu lassen und ihnen den Freiraum zu geben, noch einmal nachzuhaken, war für uns einfach realisierbar. Zusätzliche Lernangebote, wie Links zum Selbststudium, gute Quellen und Webseiten zur Verfügung zu stellen, war uns ebenso wichtig.

Ein weiterer Aspekt, den wir beleuchten möchten, ist die Wichtigkeit des Fragenstellens im Lernprozess. Im ersten Teil ihres Buch “Lernen durch Fragen” geht die Autorin Levin auf diese Thematik ein [3]. So können sich die Studierenden durch das aktive Nachdenken über den Lernstoff und den Prozess des Formulierens einer Frage tiefer mit dem Stoff auseinandersetzen. Dabei steht das Gespräch zwischen dem Lehrenden und der lernenden Person im Vordergrund. Die Aufgabe eines Lehrers besteht grundsätzlich darin, ein kindliches Interesse zu wecken. Dieses Interesse führt im Optimalfall dann automatisch zum Bedürfnis des Fragenstellens. Der Wunsch, mehr darüber erfahren zu wollen, führt zu aktivem Nachfragen, um eine gefühlte Erkenntnislücke zu schließen. Zudem führt Levin auf, dass Fragen Wissen bei der Person voraussetzt, die sie stellt. Demnach ist es nur möglich Fragen zu stellen, wenn bereits ein gewisser Kenntnisstand vorhanden ist. Für das Stellen von allgemeinen Fragen wird allgemeines Wissen benötigt. Wenn man spezifische Fragen stellen möchte, die auch die Antwortmöglichkeiten begrenzen, braucht man bereits ein tieferes Verständnis des Kontexts [3].

Ein ehrliches Interesse bei den Studierenden zu wecken, ist sicher nicht immer möglich. Die Wichtigkeit dessen, um Mitarbeit durch Fragen zu erreichen, sollte jedoch nicht unterschätzt und demnach nicht im Unterrichtsgeschehen vernachlässigt werden. Auch sind Missverständnisse bezüglich der Fragestellung und der damit unzufriedenstellenden Beantwortung auf die Tatsache des individuellen Kenntnisstandes zurückzuführen. So kann auch erklärt werden, warum die Wahrscheinlichkeit für Misskommunikation zwischen Personen mit sehr unterschiedlichen Kenntnisständen (z.B. Erstsemesterstudierende:r und Professor) häufig höher ist, als bei Personen mit ähnlichem Wissen. Tutorien von Studierenden für Studierende sind folglich ein wichtiger, zusätzlicher Baustein im Studium.

Frauen in der Informatik sind noch in der Unterzahl – das sagen nicht nur die Statistiken. Es reicht ein Blick in die Seminar- und Vorlesungsräume unserer Informatikstudiengänge an der HdM. Mit dem Ruf “Hochschule der Mädchen” ist der Anteil der “Informatik-Mädels” schon allgemein höher als an manchen anderen Universitäten – Frauen sind aber noch immer unterrepräsentiert. Aber an was könnte es liegen? Auch wenn diese Tatsache sicher sehr vielschichtige Gründe hat, bemerkt Schinzel et al [4], dass Männer sehr früh in ihrer Entwicklung in Kontakt mit Computern und Informatik kommen. Frauen hingegen haben diese Kontaktpunkte oft erst am Ende oder nach der Schulausbildung. Sie berichtet außerdem von Tutorien, die speziell für Frauen angeboten werden. Dabei war interessant, dass diese total unterschiedlich von den Frauen bewertet werden. Die allgemeine Beurteilung solcher Veranstaltungen (ohne Teilnahme) war eher negativ, da die Frauen eine Abwertung ihrer Fähigkeiten fürchten. Die Frauen, die allerdings teilgenommen hatten, haben es als Zugewinn erfahren [4]. In der von Schinzel et al angeführten Studie zeigen Studentinnen offenbar ein geringeres Selbstbewusstsein bei ihrem Studium, insbesondere in den Bereichen Programmierung, Computerwissen und Software, wie aus der Befragung hervorgeht. Im Vergleich zu den männlichen Studierenden empfinden mehr Studentinnen trotz guter Leistungen das Gefühl, fachlich den anderen Studierenden unterlegen zu sein [4].

Für uns war es wichtig, ein Tutorium für alle offen anzubieten und keine Einschränkung aufgrund des Geschlechts zu machen. Wir sind gespannt, wie sich die Verteilung von männlichen und weiblichen Teilnehmer:innen bei Fortführung des Projekts verhält.


Studie 1: Quantitative Umfrage

Zu Beginn des Semesters führten wir eine quantitative Umfrage mit 94 Studierenden aus den ersten drei Semestern Mobile Medien und Medieninformatik durch. Davon gehören 34 Personen dem Studiengangs Mobile Medien (MM) an, 60 sind im Studiengang Medieninformatik (MI) eingeschrieben.

Eine Frage in unserer Umfrage zielte darauf ab, herauszufinden, ob die Studierenden sich von ihrem Wissensstand her gegenüber ihren Mitstudierenden hinterher, auf Augenhöhe oder überlegen fühlen. Etwas mehr als zwei Drittel der Studierenden von MM gaben an (Abb. 1), mit ihrem Wissensstand hinterher oder weit hinterher zu sein. Beim Studiengang MI waren es 41% (Abb. 2). Insgesamt gaben 48 der 94 Studierenden an, hinterher oder weit hinterher zu sein. Dadurch kann unsere erste Hypothese H1 bestätigt werden. Mögliche Gründe für die Unterschiede zwischen MM und MI können nicht sicher genannt werden. Denkbar ist jedoch die technischere Ausrichtung des MI-Studiengangs und damit die Einschreibung von Personen mit mehr technischen Vorwissen als bei MM.

Abb. 1: MMB + Wissensstand
Abb. 2: MI + Wissensstand

Des Weiteren wollten wir herausfinden, wie viele der Personen ohne Vorwissen in ihr Studium gestartet sind und sich zur Zeit der Befragung fühlen, als hätten sie grundlegende Wissenslücken. Die Ergebnisse sind in Abbildung 3 zu sehen. Dabei gab knapp ⅓ aller befragten Personen an grundlegende Wissenslücken zu haben. 46% der Teilnehmenden, die ohne Vorwissen ins Studium gestartet sind, fühlen sich, als hätten sie grundlegende Wissenslücken. Nur 12% der Personen ohne Vorwissen geben an, keine Wissenslücken zu haben. Die restlichen 42% geben an, teilweise Wissenslücken zu haben. Somit gilt die zweite Hypothese ebenfalls als validiert, womit eine Verbindung zwischen fehlendem Vorwissen und grundlegenden Wissenslücken im Rahmen der durchgeführten Studie hergestellt werden kann.

Abb. 3: Person hat kein Vorwissen + hat grundlegende Wissenslücken

Außerdem wurden negative Gefühle und Reaktionen bzw. Ängste ermittelt, die aufgrund von grundlegenden Wissenslücken bei den Studierenden ausgelöst wurden. 36,2 % der befragten Studierenden haben das Gefühl, dass ihre Schwachstellen sie zurückhalten. Weitere 33% haben Angst vor schlechten Noten oder den Abschluss nicht zu schaffen. 29,8% haben das Gefühl, nicht mehr “aufholen” und damit mithalten zu können, und 25,5% der befragten Studierenden konzentrieren sich nur auf ihre Stärken (Comfort-Zone). Knapp 11% überlegen sich sogar, den Studiengang zu wechseln oder das Studium abzubrechen. Insgesamt traf die Frage auf nur 26,6% der Befragten gar nicht zu. Hypothese H3 wurde damit ebenfalls bestätigt.

Abschließend galt es herauszufinden, ob ein Hilfsangebot, wie wir es planten, angenommen werden und Personen daran teilnehmen würden. Dabei gaben 36,2 % der befragten Personen an, sehr gerne an einem solchen zusätzlichen Angebot teilzunehmen. 46,8 % der befragten Personen würden an dem Angebot vielleicht (weiß nicht/kommt darauf an) teilnehmen. Damit konnte auch eine Verifizierung der dritten Hypothese H4 erfolgen.

Studie 2: Qualitative Studie – Fokusgruppe

Zusätzlich zur quantitativen Studie wollten wir durch eine qualitative Umfrage noch detailliertere Erkenntnisse erlangen, die sich auf die konkrete Ausgestaltung des Grundlagentutoriums beziehen. Dazu haben wir uns in Form einer zweistündigen Fokusgruppe und eines einstündigen Interviews mit betroffenen Studierenden intensiv ausgetauscht. Ziel war es herauszufinden, welche Erlebnisse und Gefühle sie im Studium erlebt hatten, welche Themen(bereiche) im Tutorium bearbeitet werden sollen sowie Einzelheiten und Wünsche zur konkreten Umsetzung des Angebots. Uns war es wichtig, das Tutorium an die Bedürfnisse und Wünsche dieser Gruppe anzupassen und sie aktiv mit einzubeziehen.

An der Fokusgruppe hatten zwei Studierende teilgenommen, an dem Interview eine weitere Studentin. Dazu besuchten wir Vorlesungen der ersten drei Semester und riefen betroffene Studierenden zum Austausch auf. Zur Dokumentation und Interaktion wurde ein Miro-Board erstellt und im Laufe der Fokusgruppe und des Interviews gefüllt. Das gesamte Board inklusive aller Ergebnisse ist in Abbildung 4 zu sehen.

Abb. 4: Gesamtes Miro-Board mit Ergebnissen aus den beiden Fokusgruppen-Umfragen

Im persönlichen Gespräch wurde deutlich, dass die Studierenden von sich sagen, dass sie grundlegende Wissenslücken haben. Die Studierenden, mit denen wir gesprochen haben, sind ohne Vorwissen in ihr Studium gestartet. Alle drei Teilnehmerinnen würden sehr gerne an unserem Angebot teilnehmen. Aufgrund des inhaltlichen Feedbacks wurden die Rahmenbedingungen für das Tutorium festgelegt. Durch die qualitative Studie könnten somit H1 – H4 erneut bestätigt werden. Abbildung 5 und 6 zeigen die Ergebnisse im Detail.

Abb. 5: Ergebnisse zum Ablauf im Detail
Abb. 6: Ergebnisse zu den Themen im Detail


Neben den oben beschriebenen Umfragen führten wir auch Experteninterviews mit Prof. Walter Kriha, Dr. Tobias Jordine und Benjamin Binder durch, um die Sicht und Erfahrungen von aktiv lehrenden Personen miteinzubeziehen.

Benjamin Binder betonte im Gespräch, dass es eine Gruppe von Studierenden gibt, die von den Lehrenden nicht erreicht werden können und für die es derzeit kein Auffangnetz gibt. Während seiner Vorlesungen ist ihm zudem aufgefallen, dass diese Studierenden selten Fragen stellen. Angesichts dieser Situation sieht er einen deutlichen Bedarf für ein entsprechendes studentisches Angebot.

Tobias Jordine betonte die Bedeutung einer Unterstützung auf Augenhöhe, bei der ein sicherer Raum geschaffen wird, in dem, neben dem thematischen Inhalt, auch Raum für weiterführende Gedanken vorhanden ist. Durch seine Anregungen fühlten wir uns bestärkt, soziale Aspekte und die Vermittlung des richtigen Mindsets in die Gestaltung der Tutorium Inhalte einzubeziehen. Zudem betonte er, dass die Leistung nicht allein anhand von Noten oder dem Endergebnis bewertet werden sollte. Besonders Studienanfänger:innen haben diesbezüglich festgefahrene Muster und Verhaltensweisen, die es ihnen schwer machen, im Studium die übergeordneten Ziele zu sehen und Risiken (z.B. als Anfänger die Programmierung in einem Projekt übernehmen) einzugehen. Sie verstecken sich hinter bekannten Aufgaben und verpassen es, an ungewohnten Aufgaben zu wachsen. Zudem hatte Tobias Jordine Ideen, um einen sicheren Raum zu schaffen: kleine Erfolge feiern und betonen, dass Fehler machen dazu gehört und ganz normal im Lernprozess sind.

Als jahrelanger Professor der Softwareentwicklung kennt Prof. Kriha, die Probleme der Studierenden gut. Ein von ihm häufig beobachtetes Phänomen ist das Festkrallen am Konkreten. Studierende verlieren den Überblick und verlieren sich, besonders am Anfang des Studiums, in Details. Dieser falsche Fokus führe, laut Prof. Kriha, zu Überforderung und Angst. Viel wichtiger sei es zu lernen, abstrahiert zu denken, das übergeordnete Ziel im Blick zu behalten und Zusammenhänge anstatt alle einzelnen Details eines Themas zu verstehen. So schaffe man es auch später, im Berufsalltag effiziente Lösungen zu finden und komplexe Probleme zu lösen.

Insgesamt waren alle befragten Experten von der Idee eines Grundlagentutoriums begeistert und sehen solch ein studentisches Angebot als sehr hilfreich und wertvoll an.

Haupterkenntnisse (Zwischenstand)

Unter Beachtung aller Erkenntnisse aus den verschiedenen Studien und Befragungen haben wir uns auf ein regelmäßiges Angebot während des Semesters festgelegt. In jedem Termin (ca. 1,5h) wird ein Oberthema aus dem Bereich der Informatik und des Studiums behandelt und vorlesungsübergreifend in den Kontext gesetzt. Zudem sollte es Expertentage geben, bei denen von uns ausgewählte Experten auf dem jeweiligen Gebiet einen tieferen Einblick geben und von ihrem Arbeitsalltag erzählen. Praktische Beispiele, Demos, Hands-On-Beispiele und Mindset-Gedanken werden passend eingestreut. Der Fokus liegt auf dem übergeordneten Zusammenhang und Verständnis und nicht auf einzelnen Details.

Die Tutorien finden in einer Gruppe von maximal 12 Personen vor Ort an der HdM statt. Ein hybrides Format sollte weitgehend vermieden werden, um einen persönlichen Raum schaffen zu können. Für das Tutorium wird ein separater Raum mit Bildschirm und Whiteboard von uns reserviert und für Tee und Snacks gesorgt. Am Ende jedes Termins helfen Checkerfragen das Gehörte zu wiederholen und zu dokumentieren. Weiterführende Links zum Eigenstudium werden zur Verfügung gestellt. Die Kommunikation mit den Kursteilnehmerinnen und der Dokumentenaustausch findet zentral über einen eigenen Moodle-Kurs statt. Die Studierenden aus Semester 1 bis 3 werden per E-Mail über das Grundlagentutorium informiert und eingeladen. Sprechstunden werden zusätzlich angeboten.


Nach Auswertung der Studienergebnisse und Festlegung der Themengebiete begann die Konzeption. Es wurden relevante Unterthemen für das Verständnis eines Hauptthemas (z. B. Webentwicklung) überlegt und dabei einzelne Programmiersprachen und ihre Syntax bewusst ausgespart. Das Grundlagentutorium sollte die Informatik aus einer abstrakten Sicht erklären und sich nicht nur auf die Programmierung beschränken. Für jeden Termin wurde eine Präsentation mit den Unterthemen und Checkerfragen erstellt und den Teilnehmern einige Tage vor dem Tutoriumstermin über Moodle zur Verfügung gestellt. Zusätzlich wurde pro Termin ein Forum in Moodle eingerichtet, in dem vorab Fragen gestellt werden konnten.

Wie erwähnt, planen wir vertiefende Ergänzungen einzelner Inhalte in Form von Expertentagen. Für das Thema “Betriebssysteme & Hardware” entschieden wir uns aufgrund des hohen Interesses am Thema. Benjamin Binder als Experte und Lehrender auf diesem Gebiet erkundete mit den Studierenden das Innenleben eines Computers. Ein weiteres Thema, für das wir einen Expertentag planten, war die App-Entwicklung. Hierfür fragten wir Benjamin Kramser, ehemaliger MM-Absolvent und Frontend Engineer bei der Steuerbot GmbH, der den Weg “vom Code bis in den App Store” aufzeigte und von seiner Arbeit als App-Entwickler berichtete.


Folgende Themengebiete wurden für das Tutorium festgelegt. Die Vorstellung der einzelnen Themenblöcke inkl. Unterthemen wurde auf die verschiedenen Termine verteilt.

  1. Termin “Kennenlernen”: Kennenlernen als Gruppe, Erwartungen einholen, Organisatorisches klären, Themen und Termine vorstellen
  2. Termin “Softwareentwicklung in der Praxis”: Wie arbeitet ein:e Softwareentwickler:in? Erklärung von Git und Vorstellung nützlicher Tools
  3. Termin “Betriebssysteme & Hardware”: Expertentag mit Benjamin Binder rund um das Thema Betriebssysteme und Hardware (wie sieht ein PC von innen aus?)
  4. “Softwareentwicklung”: Vorstellung der verschiedenen Bereiche der Softwareentwicklung, die verwendeten Programmiersprachen, Debugging & Testing
  5. “Web Development”: Unterschied Front- und Backend sowie dessen Basiskonzepte (API, Kommunikation Client – Server, Datenbanken)
  6. “App Development”: Expertentag mit Benjamin Kramser (Steuerbot GmbH) mit dem Thema “vom Code bis in den App Store – aus dem Alltag eines App-Entwicklers”
  7. “Rechnernetze”: Grundlagen wie Topologien, Adressierung, Subnetting & Co.
  8. “Cloud + Security”: Was ist die Cloud und welche Vorteile bringt sie mit? Außerdem Sicherheitskonzepte, Angriffe und Hands-On Übungen 


Das erste von acht Tutorien startete Anfang Dezember, die weiteren Termine folgten in einem ein- bis zweiwöchigen Rhythmus. Es haben sich für das Tutorium ausschließlich weibliche Studierende aus allen drei Semestern gemeldet und schlussendlich daran teilgenommen. Das Tutorium war von Anfang an jedoch bewusst an alle Studierende gerichtet.

Erstes Kennenlernen

Zu Beginn des Tutoriums gab es ein kleines Kennenlernen mit Tee und Lebkuchen. Wir wollten die Erwartungen und Wünsche der einzelnen Studierenden verstehen sowie die erste Hürde als Gruppe nehmen, sodass sich alle zum ersten inhaltlichen Termin wohlfühlen konnten. Auch war es uns wichtig, uns der Gruppe vorzustellen und die Beweggründe und Motivation hinter dem zusätzlichen Angebot zu erklären. Dies war zudem eine Möglichkeit, eventuelle Missverständnisse über den Umfang oder Schwierigkeitsgrad des Tutoriums zu klären, sodass die Gruppe einen homogenen Kenntnisstand aufweist und niemand abgehängt wird oder sich langweilt.

Das Ritual von Tee und Snacks führten wir über alle Termine hinweg fort. Auch war es uns wichtig, keine klassische Sitzordnung zu wählen. Wir wollten uns bewusst vom Stil der Vorlesungen abheben und eine möglichst angenehme und lockere Atmosphäre schaffen. Dazu gehörte auch das Tragen von bequemer Kleidung, Small-Talk vor und nach dem Tutorium sowie das direkte Reinrufen von Fragen und Anmerkungen ohne Handzeichen. Auch machten wir allen zu Beginn des Tutoriums klar, dass wir selbst Vieles auch nicht wissen und das (gemeinsame) Herausfinden von Lösungen ein ganz normaler Vorgang im Informatik-Alltag ist. Uns war es jederzeit wichtig, direkt auf Augenhöhe zu kommunizieren und die Barriere zwischen uns als Tutoren und den Studierenden so klein wie möglich zu halten. 


Für uns war es außerdem von hoher Relevanz, neben fachlichen Erklärungen auch festgefahrene Glaubenssätze aufzulösen und kleine Erfolge zu feiern, um das richtige Mindset zu fördern. Wir teilten unsere Erfahrungen und Erkenntnisse mit den Studierenden, zum Beispiel über die Anforderungen an Programmierer:innen und Designer:innen sowie den Arbeitsalltag in crossfunktionalen Teams. Dabei betonten wir, wie wichtig es ist, den abstrakten Blick zu wahren, mit Rückschlägen umzugehen und Freude an eigenständigem Lernen zu haben. Unser Ziel war es, den Teilnehmerinnen Perspektiven über das Studium heraus für die Arbeitswelt aufzuzeigen und Ängste und Druck zu reduzieren. Dies half auch eigenen Fähigkeiten realistischer einschätzen und neues Selbstbewusstsein schöpfen zu können.

Feedback & Wirkung 


Während des Tutoriums beteiligten sich die Studierenden sehr aktiv, jedoch gab es kaum Interaktion in Moodle. Weder das Angebot, Fragen im Forum zu stellen, noch die angebotene Sprechstunde wurden genutzt. Keine der Teilnehmerinnen kontaktierte uns außerhalb des Tutoriums. Da es während des Tutoriums einen regen Austausch gab, war ein weiterer Austausch wohl nicht notwendig.

Zudem haben wir auch noch eine weitere Beobachtung gemacht, die, wie sich im finalen Austausch mit Tobias Jordine, Benjamin Binder und Walter Kriha herausstellte, so noch nicht gemacht wurde. Wir haben die Teilnehmerinnen des Tutoriums als sehr fleißig und begeistert an den Themen im Studium wahrgenommen. Bei Gesprächen darüber, wie Prüfungen liefen oder Prüfungsergebnisse ausgefallen sind, klang alles sehr positiv und unproblematisch. Und dennoch sind es genau diese Personen, die am Grundlagentutorium teilgenommen haben. Eine unsichtbare ruhige Gruppe, die kaum Fragen stellt, nicht als klassische Problemfälle wahrgenommen wird und (sehr) gute Noten schreibt. Eine Gruppe, bei der niemand merkt, wie viel Unsicherheit in ihren Köpfen herrscht und dass über einen Studienabbruch nachgedacht wird. Das Ganze findet im Inneren dieser Personen statt und kann nicht anhand irgendwelcher äußeren Kriterien gemessen werden. Das ist sicher auch ein Grund dafür, weshalb diese Gruppe bisher bei Analysen über Studienabgänger:innen kaum bis gar nicht beachtet wurde.

Studie 3: Quantitative Umfrage

Um die oben aufgestellten Hypothesen H5 – H8 zu validieren, führten wir am Ende des Tutoriums eine weitere Umfrage durch. Dabei ergaben sich folgende Ergebnisse:

H5: Studierende, die am Tutorium teilgenommen haben, fühlen sich sicherer mit den Buzzwords und den Zusammenhängen der Informatik.

→ Diese Hypothese konnte bestätigt werden. Alle Umfrageteilnehmerinnen haben der Aussage klar zugestimmt.

H6: Studierende, die das Tutorium besucht haben, fühlen sich besser vorbereitet als / vom Kenntnisstand aufgeholt zu den anderen Studierenden im Semester als Studierende, die kein Tutorium besuchen.

→ Hypothese 6 konnte im Rahmen der dritten Studie ebenfalls bestärkt werden. 80% der Antworten sind bejahend zu werten.

H7: Durch das Grundlagentutorium konnten grundlegende Wissenslücken für Studierende, die das Tutorium besucht haben, geschlossen werden.

→ 100% der Teilnehmerinnen stimmten dieser Hypothese zu. 

H8: Es macht für die Studierenden einen Unterschied, ob solch ein Tutorium von Studierenden angeboten wird, die mit ihrer Lebensrealität näher an den Studienbeginnern sind oder von Dozenten mit viel Erfahrung.

→ Zu dieser Hypothese konnten wir neben dem quantitativen Ergebnis von 100%iger Zustimmung auch noch detailliertere Erkenntnisse gewinnen. Als Begründung warum solche ein Angebot von Studierenden angeboten werden sollte, wurde unter Anderem die Nähe zum Studium und dessen Inhalte genannt: Studentin 1: “Bei Dozenten habe ich oft das Gefühl, das sie nicht (mehr) wissen wie man sich als Anfänger fühlt und welche Probleme man zu Beginn hat. Bei euch ist das alles noch viel präsenter und ihr könnt das besser nachvollziehen. Außerdem ist der Altersunterschied ja nicht so groß, was für mich dafür sorgt, dass ich mich wohler fühle.” oder Studentin 2: “Da Dozenten die Schwierigkeiten, die man als kompletter Neuling in diesem Themengebiet hat, oft nicht verstehen/ nachvollziehen können. Fragen, die man stellt [werden] oft falsch verstanden (ist mir leider so oft passiert in den Vorlesungen). Ihr dagegen habt immer genau verstanden, was ich mit meinen Fragen meine und sie kurz und verständlich beantwortet.”. Es half den Teilnehmerinnen, dass wir ähnliche Schwierigkeiten in unserem Studium hatten und sie sich somit mit ihren Problemen nicht alleine fühlen. Konkrete Meinung von Studentin 3: “Für mich persönlich war das Tutorium wichtig, damit meine Angst vorm Versagen kleiner wird und zu realisieren, dass es viele Leute gibt, die Schwierigkeiten im Studium haben. Sowas kommt nunmal besser rüber, wenn man mit Gleichgesinnten da durch geht.” und abschließend Studentin 4: “Die Atmosphäre ist besser, um ohne Ängste Fragen zu stellen.”.

Feedback und persönliche Einblicke der Studierenden

Von einigen Studentinnen haben wir außerdem noch weiteres persönliches Feedback und Dank mündlich oder per Mail erhalten. Dazu gehören Rückmeldungen wie “Das Tutorium war für mich ein Ort, wo ich mich nie dumm gefühlt habe, weil ihr uns ein Gefühl von Sicherheit gegeben habt.” oder “die Atmosphäre war super, man konnte Fragen stellen; man hat sich nicht geschämt, wenn man was nicht wusste”. Eine Studentin fragte sogar, ob sie nochmal am Tutorium teilnehmen darf, falls es erneut angeboten wird. 

Sehr hilfreich und wertvoll waren auch Verbesserungsvorschläge und Ideen. So wurde mehrfach gewünscht, das Tutorium auf zwei Stunden zu verlängern, um mehr Zeit für die Themen und unsere persönlichen Tipps und Erfahrungen zu haben. Auch gab es die Idee für regelmäßiges Feedback nach jedem Tutorium in Form einer kurzen Emoji-Umfrage, um herauszufinden, ob man alles verstanden hat oder es noch ungeklärte Fragen gibt. Ein weiterer Wunsch war es, mehr Informationen über die Folien festzuhalten, sodass Inhalte auch später eigenständig nochmal nachgearbeitet werden können.

Abschließendes Expertengespräch

Direkt im Anschluss an das Feedback der anwesenden Studierenden haben wir uns noch einmal mit Tobias Jordine, Benjamin Binder und Walter Kriha zusammengesetzt, um unsere Erfahrungen und Wahrnehmungen auszutauschen sowie die Fortführung des Projekts zu besprechen. 

Unser Projekt ging nicht nur darum, einigen Studierenden dabei zu helfen, sich mutiger mit dem Themengebiet der Informatik auseinanderzusetzen, sondern auch darum, eine bisher unentdeckte Gruppe zu identifizieren. Diese Gruppe besteht aus stillen, fleißigen und guten Studierenden, die jedoch unsicher und ängstlich sind. Bei ihnen besteht die Gefahr, dass ein Studienabbruch unvorhergesehen geschieht und nicht nachvollziehbar ist, da äußere Signale fehlen und ihre innere Welt nicht sichtbar gemacht oder beobachtet werden kann. Im Gespräch wurde viel reflektiert und darüber nachgedacht, wie diesen Personen geholfen werden könnte.

Gemeinsam haben wir uns auch mit der Frage beschäftigt, wie man mit solchen “Snowflake”-Lösungen wie unser Tutorium umgehen soll, die im Hochschul- und Universitätskontext nicht universal umsetzbar sind. Dabei handelt es sich um Lösungen, die speziell auf die Bedürfnisse und Wünsche von Einzelpersonen zugeschnitten sind. Für uns ist es von großer Bedeutung, dass sich diese Studierenden, auch wenn es nur ein kleiner Teil der Gesamtgruppe ist, gehört und gesehen fühlen. Solch engagierte, hoch motivierte, neugierige und zuverlässige Studierende zu verlieren, empfinden wir als äußerst bedauerlich und vermeidbar, wenn man bedenkt, mit wie vergleichsweise wenig Aufwand die Gruppe unterstützt und bestärkt werden kann.

Wir haben auch darüber nachgedacht, wie man “Snowflake”-Lösungen auf eine größere Gruppe ausweiten kann. Leider konnten wir keine endgültigen allgemeinen Ergebnisse finden, aber es wurden einige Ansätze diskutiert, die ähnliche Effekte erzielen können. Dazu gehört zum Beispiel das konkrete Nachfragen, ob auch wirklich die gestellte Frage beantwortet wurde, das Einbinden von Checkerfragen und die gezielte Verkleinerung von Tutoriumsgruppen, wo dies möglich ist. Es wird versucht, diese Ansätze auszuprobieren, um zu sehen, ob sie für eine größere Gruppe von Studierenden geeignet sind.

Abschließend haben wir einstimmig beschlossen, das Tutorium im nächsten Semester erneut anzubieten. Wir haben auch diskutiert, dass nicht jeder das Tutorium leiten können sollte, sondern dass es besser wäre, Studierende auszuwählen, die ähnliche Erfahrungen gemacht haben, ein gewisses Einfühlungsvermögen haben und bereit sind, sich verletzlich zu zeigen. So können wir sicherstellen, dass die Teilnehmer:innen bestmöglich unterstützt werden und sich in einer vertrauensvollen Umgebung wohl fühlen.


Insgesamt sind wir sehr zufrieden mit dem Projektverlauf und -ergebnis. Auch konnten wir selbst die einzelnen Themen vertiefen und haben ein erstes Gefühl bekommen, wie man schwierige Inhalte verständlich aufbereiten und erklären kann. Auch wenn sich die Teilnehmerzahl über die fortlaufenden Termine reduzierte, hatten wir bei jedem Tutorium viel Spaß und es war großartig zu sehen, wie Themen und Zusammenhänge verstanden wurden und zunehmend Fragen gestellt wurden. 

Die Erfüllung der Hypothesen stützt unser persönliches Gefühl und bestätigt die Notwendigkeit sowie den Erfolg des Grundlagentutoriums. Die grundlegenden Wissenslücken konnten geschlossen und negative Gefühle abgelegt werden. Die positiven Rückmeldungen und persönlichen Geschichten der Studierenden haben uns sehr gefreut. Neben den fachlichen AHA-Momenten macht es uns besonders zufrieden, dass auch Mindset-Änderungen bei den Studierenden stattfanden. Wir hoffen, dass sie zukünftig selbstbewusst neue Aufgaben annehmen können und ihre Leistung nicht nur an dem Endergebnis messen.

Der Wunsch, damals gerne selbst solch ein Angebot gehabt zu haben, um unseren Wissenslücken und Unsicherheiten im Studium zu begegnen, war ein großer Motivationsgrund für uns. Aus eigenen Erfahrungen wissen wir, wie wichtig solch eine Unterstützung für den weiteren akademischen und beruflichen Werdegang sein kann. Diese Gruppe an Studierenden aufzufangen und neuen Mut zu geben, kann sehr prägend und wegweisend sein, weshalb es uns eine Herzensangelegenheit ist, uns auch weiterhin dafür einzusetzen.


Abschließend möchten wir noch einmal einen kritischen Blick auf das Projekt werfen und reflektieren, ob das Projekt seinen gewünschten Effekt erzielen konnte. 

Der Rückmeldung nach war das Tutorium ein sicherer Raum, um Fragen und Unklarheiten zu adressieren. Rückblickend war es sicher wichtig, uns von Anfang an sehr ehrlich und verletzlich zu zeigen und immer wieder zu betonen, dass auch wir Vieles selbst nicht wissen und uns auch fachlich auf die Tutorien vorbereiten mussten. Wissenslücken haben wir immer gemeinsam als Team erarbeitet. Wir wollten den Studentinnen zeigen, dass sie nicht alleine in ihrer Situation sind und Nichtwissen ganz normal ist. Auch wenn es im Studium oft nicht so wirkt und man von dem Wissen und der Erfahrung der Professor:innen und Kommilitonen schnell eingeschüchtert wird, es wird nie verlangt alles zu wissen oder zu können. In der sich schnell verändernden Welt der Informatik ist es viel wichtiger, eigeninitiativ, motiviert und neugierig zu bleiben und die groben Konzepte zu verstehen. Wir haben schnell gemerkt, dass dieser Gedanke durch den Studienalltag bisher zu kurz kam und den Studierenden der Bezug zur Praxis und damit die realitätsnahe Einordnung ihrer Fähigkeiten und Stärken gefehlt hat. Des Weiteren war es uns sehr wichtig wirklich alle offenen Fragen zu beantworten. Dazu haben wir auch gezielt nachgefragt, ob wir ihre Frage richtig verstanden haben und bewusst Zeit zum Nachdenken gelassen. Beides war rückblickend sehr wichtig und sollte so fortgeführt werden.

Allgemein hatten viele der Teilnehmerinnen ein geringes Selbstbewusstsein bezüglich ihrer Fähigkeiten und Wissen in der Informatik. Auch die Tatsache, dass ausschließlich weibliche Studierende am Tutorium teilgenommen haben, bestätigt die Erkenntnisse aus dem Theorieteil im Rahmen unseres Projektes. Umso wichtiger ist es uns daher, Frauen in der Informatik zu stärken und zu ermutigen. Ihre hohe Leistungs- und Lernbereitschaft sowie ihr Interesse sollten nicht durch Ängste und fehlendem Selbstbewusstsein überschattet werden und sie zurückhalten. Unsere Geschichte und die Tatsache, dass wir, als eine von ihnen, nun erfolgreich im Studium und Beruf stehen, hat ihnen eine neue Perspektive aufgezeigt. Weibliche Vorbilder weiterhin im Studiengang sichtbar zu machen, halten wir daher als essentiell wichtig.

Auf organisatorischer Ebene hatten wir zu Beginn des Tutoriums kleine Probleme mit den Moodle-Foren. Die von uns erstellten Foren zu jedem Termin/Thema werden von uns und den Teilnehmerinnen nicht automatisch abonniert. Diese Default-Einstellung war uns nicht bewusst. Es führte anfangs dazu, dass wir Nachrichten von Teilnehmerinnen übersehen hatten und zu unseren Nachrichten keine E-Mail Benachrichtigung versendet wurde. Diese Hürde wurde jedoch schnellstmöglich behoben und alle Foren auf “verbindliches Abonnieren” umgestellt. 

Grundsätzlich eignet sich Moodle als Plattform zur Kommunikation und Informationsaustausch gut für unsere Zwecke, da an der HdM jeder Studierende bereits damit gearbeitet hat. Wie oben erwähnt, nahm die Teilnehmerzahl im Verlauf des Tutoriums ab. Die Gründe waren dabei unterschiedlicher, zeitlicher Natur. Wir halten es für wichtig, das kommende Tutorium nicht mehr in der vorlesungsfreien Zeit abzuhalten und das Abmelden bei Nichterscheinen nochmals deutlicher zu kommunizieren und einzufordern. Es war schade, dass wir Studierenden aufgrund voller Teilnehmerzahl absagen mussten, ein paar wenige, angenommene Teilnehmer dann aber ab dem 2. Termin nicht mehr erschienen sind.

Ausblick: Weiterführung des Projekts

Grundsätzlich streben wir an, das Grundlagentutorium im kommenden Semester erneut anzubieten. Da man im folgenden Semester direkt zu Semesterbeginn mit der Durchführung starten kann, wird es zudem möglich sein, alle Tutorien innerhalb der Vorlesungszeit abzuhalten. Die Konzeption des jetzigen Semesters wird dabei größtenteils übernommen und mit dem Feedback der Studierende und unseren Learnings verbessert bzw. angepasst. Je nach Interesse der Studierenden wird auch der terminliche Rahmen und Teilnehmerzahl entsprechend neu geplant. Über eine Anwesenheitspflicht und eine ECTS-Vergütung für die Tutoren wird nachgedacht.

Leider wird Kim kommendes Semester auf Grund ihrer Masterarbeit nicht mitwirken können. Erfreulicherweise hat sich jedoch die Studentin bereit erklärt, Tamara zu unterstützen, durch die dieses Angebot inspiriert wurde. Wir sind begeistert, dass wir bei ihr so viel Selbstvertrauen und Mut geweckt haben und freuen uns, mit ihr das Grundlagentutorium weiter zu gestalten.

Abschließend möchten wir uns nochmal bei allen Teilnehmerinnen für ihre Offenheit, ihr Vertrauen und ihre Mitarbeit bedanken, die für uns das Projekt erst richtig wertvoll gemacht haben. Ihr seid alle wirklich klasse und wir sind uns sicher, dass ihr euer Studium und Berufsleben rocken werdet!


[1] Schwill, Andreas; Fundamentale Ideen der Informatik, Fachbereich Informatik, Universität Oldenburg,

[2] ‘Nur’ Geschmackssache? : Der Umgang mit kreativen Leistungen im Musik- und Kunstunterricht (2020),  Schwarzbauer,Michaela und Steinhauser, Katharina und Friedl, Juliane, LIT, Wien 

[3] Levin, A. (2005). Lernen durch Fragen. Wirkung von strukturierenden Hilfen auf das Generieren von Studierendenfragen als begleitende Lernstrategie. In D.H. Rost (Hrsg.): Reihe Pädagogische Psychologie und Entwicklungspsychologie, Band 48, Münster: Waxmann.

[4] Schinzel, B., Kleinn, K., Wegerle, A. et al. Das Studium der Informatik: Studiensituation von Studentinnen und Studenten Ziel ist die Stärkung des Selbstbewußtseins von Frauen in der Informatik. Informatik-Spektrum 22, 13–23 (1999).

Wie Ticketmaster Taylor Swift verärgerte und was Software Developer daraus lernen können

Verkaufsstarts für große Ereignisse wie Konzerte oder Sportveranstaltungen sind immer mit Spannung erwartete Ereignisse. Doch wenn es bei diesen Verkaufsstarts zu Problemen kommt, kann dies für Veranstalter und Kunden gleichermaßen ärgerlich sein. Ein bekanntes Beispiel hierfür ist das Debakel von Ticketmaster bei dem Verkauf von Taylor Swift Tickets für ihre “Eras Tour” letzten November. Aufgrund technischer Probleme war es für Kunden nur schwer möglich Tickets zu kaufen, was zu Frustration und Enttäuschung führte.

Doch wie kam es dazu? Das ist nicht das erste Mal, dass ein System unter zu großer Last zusammenbricht. Black Friday ist hier ein bekanntes Beispiel. Selbst Ticketmaster ist das in der Vergangenheit schon mehrfach passiert. Doch Taylor Swift hat die Aufmerksamkeit darauf noch einmal erhöht und bevorstehende Großevents, wie die Beyoncé Tour, erhöhen die Relevanz weiter. In diesem Blogeintrag werden wir zunächst die Taylor Swift Situation untersuchen, um herauszufinden wie es aus technischer Sicht dazu kommen konnte. Anschließend schauen wir auf mögliche Maßnahmen, die helfen können, um in der Zukunft besser mit solch starken Anstiegen im Traffic umzugehen und Abstürze zu vermeiden.

Was passiert ist

Taylor Swift ist eine der beliebtesten Musikerinnen des letzten Jahrzehnts und ihre Fans haben ihre Rückkehr auf Tournee sehnlichst erwartet. Im Jahr 2022 veröffentlichte sie ein neues Album und kündigte die zugehörige „Eras Tour“ an. Ihre erste seit sechs Jahren. Entsprechend groß war der Andrang auf die Tickets. Der Kartenverkauf erwies sich jedoch für viele als chaotisch und frustrierend, da das System von Ticketmaster unter dem Gewicht einer noch nie dagewesenen Nachfrage überlastet war.

Wie Ticketmaster sich auf den Ansturm vorbereitete

Der Verkauf der Tickets startete am 15. November 2022. Zum Verkauf standen insgesamt 2,4 Millionen Tickets für 52 verschiedene Shows. Aufgrund dieser hohen Zahlen und der großen Bekanntheit von Taylor Swift war schon im Vorhinein klar, dass es einen großen Andrang auf die Tickets geben wird. Um diesen Andrang zu steuern und gleichzeitig Bots und Scalpers vom Kauf der Tickets fernzuhalten wurde das eigens entwickelte System Verified Fans eingesetzt. Ein Konto bei Verified Fan war Voraussetzung, um Tickets erwerben zu können, denn von dort bekam eine begrenzte Anzahl an Fans einen eindeutigen Code, mit dem sie Zugang zum Ticketkaufprozess erhielten. Insgesamt haben sich 3,5 Mio Fans bei Verified Fans angemeldet. Von diesen erhielten am Verkaufstag 1,5 Mio nach Zufallsprinzip einen direkten Zugangscode und die restlichen 2 Mio Fans wurden zu einer Warteschlange hinzugefügt. Auf diese Nachfrage war das System eingestellt.

Thundering Herd stürmt das Ticketmaster System

Zur Überraschung von Ticketmaster wurde die Website am Tag des Kartenverkaufs jedoch von weit mehr Besuchern überschwemmt als erwartet: 14 Millionen versuchten auf die Website zuzugreifen. Deutlich mehr als die geplanten 1,5 Millionen Fans. Der übermäßige Datenverkehr wurde unter anderem durch Bots und Scalpers verursacht, die eigentlich gar keinen Zugang zur Website hätten haben sollen sowie durch Fans, die keinen Code erhalten hatten, aber trotzdem versuchten auf die Website zuzugreifen.

Eben solch eine enorme Menge an Personen, die schlagartig, zur gleichen Zeit Anfragen stellen, wird auch als Thundering Herd bezeichnet. Vorstellen kann man sich das im Prinzip wie eine Horde wildgewordener Stiere, die auf das Ticketmaster System losgeht und es förmlich niederstampft. Das Thundering Herds Problem entsteht, wenn eine Menge an Clients oder Prozessen plötzlich und zur gleichen Zeit auf eine bestimmte Ressource zugreifen wollen. Auf diese schlagartig gestiegene Nachfrage ist die Ressource nicht vorbereitet und kann nicht alle gleichzeitig bearbeiten. Als Folge stürzt sie ab und steht nicht mehr zur Verfügung. Daraus kann als Resultat ein Cascading Failure entstehen, wenn die unbearbeiteten Requests sich auf andere Netzwerkknoten verteilt.

Cascading Failure führt zu Systemfehlern und Abstürzen

Ein Cascading Failure in der IT bezieht sich auf eine Situation, in der ein Fehler in einem Teil des Systems eine Kettenreaktion auslöst, die schließlich zu einem vollständigen Systemausfall führen kann. Auslöser kann der Ausfall eines einzelnen Knotens oder Teilsystems sein, wodurch die Last auf weniger Knoten des verbleibenden Systems verteilt wird. Dadurch steigt die Wahrscheinlichkeit weiterer Systemausfälle, was zu einem Schneeballeffekt führt. Cascading Failures sind äußerst kritisch, da sie einen gesamten Dienst innerhalb kurzer Zeit lahmlegen und menschliches Eingreifen erforderlich machen können.

Eben solch einen plötzlichen Ansturm wie eine Thundering Herd und somit Überlastung des Systems erlebte Ticketmaster. Das führte zu einem Cascading Failure und letztendlich zu Systemfehlern und Abstürzen der Seite. Ein wesentliches Problem war, dass es keine Begrenzung für die Anzahl der angenommenen Requests gab. User konnten immer wieder, während sie noch auf die Antwort zu ihrer ersten Anfrage warteten, ungeduldig weitere Requests schicken, ohne dass diese abgelehnt wurden. Gleichzeitig ließ das Bots freie Hand, sodass unter anderem DDoS Attacken ausgeführt werden konnten. Insgesamt summierte sich die Anzahl an Requests so auf rund 3,5 Milliarden! Das Überstieg den vorherigen Spitzenwert um das Vierfache.

Abb. 1: Traffic-Verlauf auf der Ticketmaster Website letztes Jahr macht die Thundering Herd sichtbar [1]

Fans am Boden zerstört, Taylor Swift wütend

Die Auswirkung: das System war völlig überlastet, wodurch es zu verschiedensten Systemfehlern kam. Fans wurden von der Warteliste gestrichen und verloren Tickets, die sich bereits in ihrem Einkaufswagen befanden. Rund 15% der Interaktionen auf der Seite enthielten Fehler. Um das System wieder zu stabilisieren, wurden mehr Fans in Warteschlangen gesetzt. Sie mussten so stundenlange Wartezeiten in Kauf nehmen, um zum Teil am Ende nur eine Fehlermeldung angezeigt zu bekommen. Die Erfahrung war so frustrierend, dass sogar Taylor Swift ihre Verärgerung zum Ausdruck brachte:

“I’m not going to make excuses for anyone because we asked [Ticketmaster], multiple times, if
they could handle this kind of demand and we were assured they could. … It really pisses me
off that a lot of [fans] feel like they went through several bear attacks to get them.”

– Taylor Swift [2]

Doch was kann verbessert werden, dass es nicht noch einmal zu so einer Situation kommt und auf so eine große Nachfrage besser reagiert werden kann?

Wie in Zukunft alle Swifties glücklich werden könnten

Der erste Gedanke, um mit solch einem Traffic Spike umzugehen: Skalieren. Letztendlich braucht es deutlich mehr Kapazitäten, um die Masse an Requests bearbeiten zu können.

1. Horizontales skalieren

Eine Möglichkeit das zu erreichen ist über horizontales Skalieren. Darunter wird die Möglichkeit verstanden, die Anzahl an System Ressourcen gemäß den Kapazitätsansprüchen anzupassen. Im Gegensatz zum vertikalen Skalieren wird die Kapazität nicht über die Verbesserung einzelner Komponenten oder die Erhöhung der Leistungsfähigkeit der vorhandenen Ressourcen verändert. Stattdessen werden zusätzliche Ressourcen, wie zum Beispiel weitere Server oder Computer, hinzugefügt, um die Kapazität eines Systems zu erhöhen. Das horizontale Skalieren bietet insbesondere den Vorteil, dass relativ einfach und schnell zusätzliche Kapazitäten geschaffen werden können, um den Workload zu bearbeiten. Ticketmaster setzt bereits seit 2014 auf Microservices. Daher eignet sich die Infrastruktur gut für eine horizontale Skalierung.

Dabei gibt es zwei Ansätze, wann die Skalierung erfolgen kann:

  • Pre-Scaling über eine Kapazitätsplanung:

Mithilfe einer Kapazitätsplanung kann im Voraus festgelegt werden, ob, wann und wie skaliert werden soll. Dadurch kann sichergestellt werden, dass jederzeit genügend Ressourcen zur Verfügung stehen. So kann beispielsweise zu bestimmten Peaks eingeplant werden, dass mehr Rechenkapazität bereitgestellt werden muss. Wichtig hierfür ist, dass bekannt sein muss, wie sich die Nachfrage verhält, um so gezielt zu skalieren.

Ein großes Problem bei dem Ticketmaster Debakel war sicherlich, dass die tatsächliche Load unterschätzt wurde. Es wurde keine ordentliche Kapazitätsplanung durchgeführt. Insgesamt standen zu wenig Rechenkapazitäten zur Verfügung, sodass die Systeme, à la Thundering Herd, förmlich überrannt wurden.

  • Auto-Scaling:

Der Nachteil am Pre-Scaling ist, dass die Ressourcen beansprucht werden, auch wenn es doch nicht zu der erwarteten hohen Nachfrage kommt. Entsprechend kann diese Methode kostenintensiv sein. Daher kann stattdessen Auto-Scaling sinnvoll sein. Beim Auto-Scaling wird die zur Verfügung stehende Ressourcenanzahl je nach vorherrschender Nachfrage dynamisch vom System angepasst.

Nachteil am Auto-Scaling ist, dass es nicht in Sekundenschnelle funktioniert. Zwar können kurzfristig automatisch mehr Kapazitäten zur Verfügung gestellt werden, trotzdem braucht es etwas Vorlaufzeit. Gerade bei einem Spike, wie es beim Taylor Swift Kartenverkauf der Fall war, ist so eine Methode zu langsam, um einen Systemabsturz vollends zu verhindern.

Im Fall von Ticketmaster ist eine Mischung aus beiden Skalierungsweisen sinnvoll. Anhand eines passenden Kapazitätsplans sollten genügend Ressourcen eingeplant und zur Verfügung gestellt werden. Sollte diese Annahme dennoch übertroffen werden muss Auto-Scaling ermöglicht sein, um kurzfristig reagieren und auch diese Nachfrage bedienen zu können.

2. Bot Management

Wie bereits beschrieben war ein Grund für die hohe Requestanzahl am 15. November, dass entgegen der Erwartung Bots auf der Seite waren. Präventive Maßnahmen wie der Einsatz des Verified Fan Systems waren also nicht erfolgreich. Ein adäquates Bot Management, um den Bottrafic zu stoppen hätte geholfen.

Ziel des Bot Managements ist es schlechte Bots zu identifizieren, um sie anschließend zu blockieren und so eindämmen zu können. Damit soll der ordnungsgemäße Betrieb des Systems und die Sicherheit der Benutzer und Daten gewährleistet werden. Mögliche Maßnahmen können sein:

  • Rate Limiting

Rate Limiting ist ein Verfahren um die Überlastung eines Servers zu verhindern, indem die Anzahl der Anfragen, die ein Client an einen Server sendet, begrenzt wird. Wenn ein Client versucht mehr Anfragen als die festgelegte Rate zu senden, wird die überschüssige Anfrage entweder abgelehnt oder in eine Warteschlange gestellt, bis die Rate wieder unter der Grenze liegt.

Gerade so eine harte Grenze hätte Ticketmaster geholfen, dass es nicht zu den 3,5 Milliarden Requests kommt. Insbesondere als grundlegender Schutz gegen DDoS Attacken wäre der Bot Traffic so deutlich verringert worden.

  • Anzeichen für Bot Traffic früh erkennen

Ein Anzeichen kann ein Anstieg an fehlgeschlagenen Logins in User Konten sein, da es eine Art des Angriffes ist User Konten zu übernehmen und mithilfe dieser den Angriff durchzuführen. Für gewöhnlich ist auch ein plötzlicher, starker Anstieg an Traffic ein Anzeichen für einen möglichen Bot Angriff. Allerdings war hier ähnlich wie auch zu Events wie Black Friday sowieso mit einem Traffic Spike zu rechnen. Daher hilft diese Information für den Ticketmaster Fall nicht.

3. Message Queues

Eine weitere Möglichkeit, um die Systeme bei einer Thundering Herd stabil zu halten, ist über den Einsatz einer Message Queue oder auch Warteschlange. Diese dient als Puffer zwischen den Clients und Servern. Die Request werden dort zunächst abgelegt und dann asynchron, sobald Rechenkapazität verfügbar ist, weiterverteilt. Das System kann so Anfragen aus der Queue abarbeiten, ohne dass es durch eine große Anzahl von gleichzeitigen Anfragen überlastet wird.

Zusätzlich bietet eine Queue die Möglichkeit die Anzahl an Anfragen, die ein System annehmen kann, zu begrenzen. Sobald die Queue voll ist, können keine weiteren Anfragen mehr angenommen werden und neue Clients bekommen einen Fehler angezeigt. Warteschlangen hat Ticketmaster bereits eingesetzt. Insbesondere eine harte Grenze hätte jedoch helfen können die Anzahl an Requests, die gleichzeitig zu bearbeiten sind, zu reduzieren und die Thundering Herd abzuschwächen.

4. Caching

Eine weitere Möglichkeit das Thundering Herd Problem abzuschwächen ist Caching einzusetzen, um vielfach verwendete Daten zwischenzuspeichern und somit schneller verfügbar zu machen. Im Falle von Ticketmaster eignen sich insbesondere Meta-Daten über das Event also bspw. wann findet es statt, wer ist der Act, wo findet das Konzert statt.

5. Testen, Testen, Testen

Ein weiterer wichtiger Aspekt ist das Testen. Ein Fehler kann einen Cascading Failure auslösen und zu großen Systemfehlern und Abstürzen führen. Entsprechend ist es wichtig das System und seine Komponenten ordentlich zu testen, um die Wahrscheinlichkeit eines solchen Fehlers möglichst gering zu halten. Dabei gilt es nicht nur die Funktionalität zu prüfen, sondern auch nicht funktionale Aspekte, wie bspw. welcher Load ein System standhalten kann. Insbesondere in Hinblick auf ein geplantes Großevent wie der Verkaufsstart von Taylor Swift Tickets sollte ein System getestet werden, um zu prüfen, ob das System vorbereitet ist. Möglichkeiten ein System auf seine Widerstandsfähigkeit zu prüfen sind dabei:

  • Load Testing: Simulieren einer bestimmten Load, um zu prüfen, wie sich das System unter bestimmten Loads verhält. Es werden bspw. Antwortzeiten und Durchsatz des Systems gemessen.
  • Scalability Testing: Testen, ob das System fähig ist, sich an verschiedene Loads anzupassen und entsprechend zu skalieren.
  • Stress Testing: Überprüfung der Leistungsfähigkeit eines Systems unter extremen Bedingungen, die über die erwartete oder normale Arbeitslast hinausgehen. Im Gegensatz zu Load Testing geht es hier darum die Kapazitätslimits eines Systems aufzudecken.
  • Chaos Engineering: Methode, um die Widerstandsfähigkeit eines Systems gegenüber unerwarteten Ereignissen und Fehlern zu verbessern, indem gezielt Chaos eingeführt wird. Es werden kontrolliert Störungen und Fehler ausgelöst, um zu sehen, wie das System auf diese Ereignisse reagiert und ob es in der Lage ist sich selbst wiederherzustellen. Bekanntes Beispiel: Netflix’s Simian Army.
  • Monitoring: Die Überwachung der Systeme in Echtzeit, um Probleme, Engpässe oder Schwachstellen frühzeitig identifizieren und entsprechend reagieren zu können.
  • Testing in Production: Das Durchführen von Tests in der produktiven Umgebung, um die tatsächliche Leistung und Reaktionsfähigkeit des Systems unter realen Bedingungen zu bewerten. Zwischen speziellen Testumgebungen und der Produktion gibt es oft große Unterschiede. Über das Testen in Produktion können daher Fehler identifiziert werden, die in speziellen Testumgebungen vielleicht nicht entdeckt worden wären. Dieses Zitat bringt es auf den Punkt:

„I’m more and more convinced that staging environments are like mocks – at best a pale imitation of the genuine article and the worst form of confirmation bias. It’s still better than having nothing – but “works in staging” is only one step better than “works on my machine”.“ [13]

Insbesondere Stress Testing und Chaos Engineering hätten bei der Ticketmaster Situation sicherlich geholfen Fehler und potenzielle Bottlenecks im Voraus zu identifizieren. Mit den Testarten lässt sich eine Thundering Herd simulieren und beobachten, wie das System darauf reagiert und ob es sich selbst wiederherstellt. Da genau so eine Stress bzw. Chaos Situation eingetreten ist hätte man über entsprechende Tests sehen können, dass das System auf eine solche Situation nicht vorbereitet ist. So hätte man die Fehler vorher lösen und mit der Thundering Herd klarkommen können. Dabei ist zu empfehlen diese Tests ebenfalls im produktiven System auszuführen, um möglichst nah an den realen Bedingungen zu sein. Denn wenn man es nicht vor dem geplanten Tag in Produktion schafft, wie soll es dann an dem Tag funktionieren?

Lessons Learned für Ticketmaster und Fazit

Die richtige Kapazitätsplanung mit ausgiebigen Stress und Chaos Engineering in produktiven Umgebungen, der direkten Bereitstellung einer Queue mit harter Grenze und der Begrenzung der Requests über Rate Limiting sind wichtige Aspekte die helfen können, um einer Thundering Herd vorzubeugen und diese im Ernstfall abzuschwächen.

Ob Ticketmaster aus dem Debakel mit dem Taylor Swift Kartenverkauf gelernt hat, konnten sie bereits kürzlich unter Beweis stellen. Anfang Februar dieses Jahres kündigte Beyoncé eine neue Tour an. Wie auch Taylor Swift ist sie eine weltweit bekannte und beliebte Sängerin, die zuletzt 2016 auf Tour war. Entsprechend war auch hier mit einer überdurchschnittlich hohen Nachfrage zu rechnen.

Ein großer Unterschied zum vorherigen Kartenverkauf war, dass sich Ticketmaster diesmal dazu entschied, nicht alle Tickets für alle Shows zur gleichen Zeit zum Verkauf freizugeben. Stattdessen wurden die Konzerte je nach Region in drei Gruppen, mit zeitlich versetzten Verkaufsstart eingeteilt. Bei Taylor Swift wurden dagegen zur gleichen Zeit 2,4 Millionen Tickets zu 52 Shows angeboten.

Auch scheint es so, als würden sie diesmal Rate Limiting eingesetzt haben. Ein paar Fans klagten über die Fehlermeldung 403. Ticketmaster gab dazu an, dies eingesetzt zu haben, um „known Bad Traffic“ zu blockieren. Insgesamt wurden so allein im Verkauf für Londoner Konzerttermine 1,5 Mio Requests blockiert. Sobald ein User die Website mehr als einmal innerhalb von 3 Sekunden aktualisiert oder innerhalb von 24 Stunden mehr als 1000 Seiten auf Ticketmasters Website besucht erscheint die 403 Fehlermeldung.

Insgesamt verliefen die Ticketverkäufe deutlich ruhiger als im vergangenen Jahr. Allerdings weiterhin nicht fehlerfrei. Es gab keinen großen Systemzusammenbruch, trotzdem gab es individuell einige Fehlermeldungen und weiterhin längere Wartezeiten.

Es scheint so, als konnte Ticketmaster zumindest zu großen Teilen aus dem Systemzusammenbruch bei Taylor Swift lernen. Trotzdem scheint es noch weiteres Verbesserungspotenzial zu geben.

Etwas Gutes hatte die Sache: in der Zeit, in der die Fans in den Ticketschleifen verweilen mussten, hatten sie sehr viel Zeit kreative neue Memes und Posts zu erschaffen. Hier nur zwei:


(Letzter Zugriff: 24.02.2023)
[2] How Ticketmaster became the most hated name in music, (Letzter Zugriff: 22.02.2023)
[3] The thundering herd — Distributed Systems rate limiting, (Letzter Zugriff: 21.02.2023)
[4] How to Avoid Cascading Failures in Distributed Systems, (Letzter Zugriff: 21.02.2023)
[5] When Taylor Swift crashed Ticketmaster: A lesson on scaling for spikes, (Letzter Zugriff: 25.02.2023)
[6] How AWS Powered Amazon’s Biggest Day Ever, (Letzter Zugriff: 23.02.2023)
[7] Getting Ready for Some Holiday Shopping? So Are the Bots., (Letzter
Zugriff: 20.02.2023)
[8] Rate limiting — A Good Approach for Scalable System, (Letzter Zugriff: 24.02.2023)
[9] Part 3 — Complete System Design Series, (Letzter
Zugriff: 24.02.2023)
[10] Spikability – An Application’s Ability to Handle Unknown and/or Inconsistent Load, (Letzter Zugriff: 25.02.2023)
[11] Testing in Production, the safe way, (Letzter Zugriff:
[12] How to increase robustness of a large scale system by testing, (Letzter Zugriff: 26.02.2023)
[13] Tweet von Cindy Sridharan,
07 (Letzter Zugriff: 25.02.2023)
[14] Beyoncé tour: UK fans snap up tickets despite Ticketmaster glitches, (Letzter Zugriff: 26.02.2023)
[15] Why am I seeing a 403 or Forbidden error message?, (Letzter Zugriff: 26.02.2023)

How Riot Games created their own internet

Riot Games is the developer of a number of big on- and offline games, most notably ‘League of Legends’. League of Legends is a real-time multiplayer online battle arena game, where two teams consisting of five players each fight one another. As the game is a fast past real-time game, split-second decisions can be the deciding factor between winning and losing a game. Therefore, low latency times are one of the core concerns of Riot Games. The Game currently has around 150 million active players world wide[8]. Back in 2014, Riot Games took a closer look at what they needed to ensure that as many of their players as possible get to have the best possible experience. They identified a number of problems and came to an interesting conclusion: They needed to create their very own internet.

The Problems

Real-time multiplayer games, like League of Legends of Riot Games,have very demanding requirements regarding the latency of a connection. If you open up YouTube in your Browser and the site takes one or two seconds to load, that is totally fine. In a real-time game like League however, where split-second decisions and reactions can decide the outcome of a Match, your game taking one or two seconds to receive the newest game state has a huge impact. Therefore, real-time games have great interest in keeping latency as low as possible.


Real-time games cannot lessen the impact of latency spikes using methods like buffering. To revisit the previous example, when watching a video on YouTube, it is exactly known what information is going to be requested, allowing the next few seconds of the video to already being buffered. If the latency spikes, the video can still run for a few seconds while it waits for new data to arrive. However, real-time games like League of Legends are not predictable as they are completely dependent on user input. Therefore, a slower response time will always be noticeable.


The ‘internet’ is not a single, unified entity. It is made up of multiple backbone companies and Internet Service Providers(ISP). And these companies have vastly different priorities than companies like Riot Games. Riot Games wants their data to take the most latency efficient path. On the other hand, backbone companies and ISP will use the most cost efficient path, even if that one will take longer.

Figure 1: Map showing the routing connection from San Jose to Hillsboro. The optimal connection is marked in light green, while the actual connection is shown in red[1].

In Figure 1, a real traffic flow of a League of Legends player is shown. The player, in the San Jose area, tries to connect to the Hillsboro area. The optimal connection is marked in light green and would connect directly from San Jose to Hillsboro. In reality, the traffic flows to Los Angeles, over Denver, then to Seattle until finally reaching Hillsboro. In Figure 1, the path is marked in red. The optimal connection (green) would take 14 ms, while the actual connection (red) takes 70 ms, which makes a huge difference.


Another problem lies in the size of Riot Games traffic. Most internet traffic is transmitted in 1500 bytes sized packages[2]. In comparison, Riot Games traffic is usually relatively small, around 55 bytes, as it might only contain simple data like the location of a player’s click.

Figure 2: Size comparison of standard internet traffic and Riot Games traffic[1].

The problem with this size difference is that routers have the same processing overhead for packets of any size, meaning that for the router, every packets costs the same amount of work. To send the same amount of data as standard internet traffic, Riot Games needs to send around 27 packets. From the routers perspective, these packets cost the same amount of work as normal packets, meaning that Riot Games traffic has an 27x cost increase compared to the standard traffic. Furthermore, routers have an input buffer, that could theoretically hold the increased number of packets. But the buffers are not only limited by size, but also by a fixed number of packets, meaning that Riot Games also fills these buffers 27x as fast[3]. If the buffer is full and another package arrives, it will be dropped by the router, resulting in package loss in the game. As a result, a player would experience things like taking damage out of nowhere and similar things.

Figure 3: An illustration of the connection from a player in San Jose to the game server in Chicago[4].

Figure 3 shows a summary of all the problems that can occur while connecting a player to the game server: The traffic from the player first has to go through ISP access networks, is then routed across different routers, which may be already busy, increasing the chance of overburdening the routers, resulting in package loss.

Riot Games saw all these problems and intended to improve the situation. Their solution: Riot Direct, which basically turns the situation shown in Figure 3 into this:

Figure 4: The connection of a player in the San Jose area to the Chicago game servers using Riot Direct[4].

Riot Direct

After identifying all these problems shown above, Riot Games came to the conclusion, that the best solution is for them to create their own internet. The requirements they have are just too different from the ISPs. The ISPs want to have a network with as many routers as possible, to allow for as much traffic as possible, while routing along the most cost efficient path. In contrast, Riot Games wants to route the most time efficient path and also does not need excessive amounts of routers, which would just increase their latency.
So Riot Games got to work and started identifying the fastest fiber routes and co-locations with the most ISPs. They started setting up routers in these co-locations and peered with as many of the other ISPs as possible. Riot Games needed to be connected with as many ISPs in as many places as possible, as users data still needs to first go through their ISPs network to reach Riot Games network. Riot Games not only had to deal with hardware, but also with software side issues, mostly with the standard internet routing protocol, ‘Border Gateway Protocol (BGP)'[5]. The BGP is build for the common use of the ISPs, and therefore has multiple problems with the special requirements of Riot Games network.
One example of the problems with BGP is traffic leaving Riot Games network.

Figure 5: The routes of incoming traffic (green) and outgoing traffic (red) of players with the same ISP in different areas of the US[4].

In Figure 5, the incoming (green) and outgoing (red) traffic of Riot Games servers in Chicago is shown. In this case, Riot Games peered with the same ISP in the Hillsboro and Chicago area. Players in the Chicago area of this ISP would enter Riot Games network through the Chicago peering point, and when Riot Games sent traffic back, it would return to the players the exact same route. Players from the Hillsboro area of the same ISP would enter Riot Games network through the Hillsboro peering point. However, when Riot Games tried to send traffic back to those players, the BGP would compute the fastest route from the Riot Games network in Chicago to the ISP network. As they peered with the ISP in Chicago, that meant that the return traffic would leave Riot Games network in Chicago and was routed entirely through the ISPs network, effectively bypassing Riot Games Network. To fix this, Riot Games worked together with the ISPs and had them mark their traffic using ‘BGP Communities'[6]. This allowed Riot Games to create special rules for the return of traffic.

The Results

Riot Games released some statistics they used to measure the improvement their changes brought. For the statistics, they measured the number of players with a latency under 80 ms.

Figure 6: Riot Direct impact 21.11.2014 – 18.8.2015[4]

As shown in Figure 6, while Riot Games was working on establishing Riot Direct, the percentage of players with a latency of under 80 ms started out somewhere between 30 – 35 %. By the end of their work, that percentage climbed to around 50% of players. Furthermore, their servers used to be located on the east coast, but with the introduction of Riot Direct, they moved their servers to Chicago, a more central location.

Figure 7: Impact of the Chicago server move[4]

The impact of the server move to Chicago is shown in Figure 7. The percentage of players with a ping below 80 ms further increased from around 50% to 80%. All in all, Riot Games managed to increase the playing experience of around 50% of the players in the US, which is a huge success.


The modern internet is always evolving. In the past, every aspect was left to ISPs and backbone companies, which would deliver a one-size-fits-all approach. And for the longest time, this was completely okay. However, the internet has grown grown exponentially, and the requirements that individual companies may have has also greatly diversified. Riot Games looked at the state of the internet of their time, and realized that it simply was not build in the way they needed it to be. As a result, they spent a lot of time and effort to create ‘their own internet’, as close to their requirements as they could. Netflix came to a somewhat similar conclusion with their Netflix Open Connect[7]. And as the internet will continue to grow, even more companies will find that they have their own special kind of requirements for ‘their’ internet, and will continue to influence and adapt the current network to their uses.


[1] Peyton Maynard-Koran, “Fixing the Internet for Real Time Applications: Part I”, (06.03.23)

[2] Wikipedia, Ethernet frame, (06.03.23)

[3] Guido Appenzeller, Isaac Keslassy, Nick McKeown, “Sizing Router Buffers”, (06.03.23)

[4] Peyton Maynard-Koran, “Fixing the Internet for Real Time Applications: Part II”, (07.03.23)

[5] Wikipedia, Border Gateway Protocol, (07.03.23)

[6] “Understanding BGP Communities”, (07.03.23)

[7] “A cooperative approach to content delivery”, (07.03.23)

[8] League of Legends Live Player Count and Statistics, (07.03.23)

How classical MMO-RPGs work, starring Final Fantasy XIV

Promotion Material Final Fantasy XIV [2]


MMO-RPGs oder Massiv-Multi-Player-Role-Playing-Games standen schon lange vor Facebook, Twitter und Co. vor der Herausforderung ein System für möglicherweise Millionen von Usern zeitgleich zu designen, dass ein Concurrent Gameplay und eine Concurrent Gameworld ermöglicht.

Doch wie konnten Spiele wie World of Warcraft, Everquest und Guild Wars diese Aufgabe ohne die Hilfe neuartiger Cloud- und Edge-Computing-Möglichkeiten lösen? Und welche Schlüsse können wir daraus ziehen, wenn wir ein System designen müssen, auf dem viele User zeitgleich agieren können? Muss es immer die Cloud sein? Oder können maßgeschneiderte Architekturen genauso gut funktionieren?

Hierfür schauen wir uns den groben Aufbau klassischer MMO-RPGs an und werden sehen, wie diese funktionieren. Final Fantasy XIV wird uns hierfür immer wieder als Beispiel dienen, um die Konzepte zu unterfüttern.
Unter klassischen MMO-RPGs verstehen wir für diesen Blogeintrag übrigens Spiele wie:

  • Final Fantasy XIV
  • Everquest II
  • World of Warcraft
  • Guild Wars 2
  • Lost Ark

MMO-RPG Server-Architecture

Stellen wir uns die Frage, was man für ein MMO-RPG benötigt, was muss es uns als Spieler bieten?

  1. Eine persistente Welt, in der Änderungen die wir durchführen, beim Ausloggen nicht verloren gehen.
  2. Die Möglichkeit, zusammen mit anderen Spielern zeitgleich Aktionen in der Spielwelt auszuführen und ihre Auswirkungen direkt zu bemerken. Zum Beispiel zusammen gegen den gleichen Feind kämpfen und den Schaden der anderen Spieler direkt sehen.
  3. Interaktion mit anderen Spielern zum Beispiel PvP (Player versus Player)

Um all dies überhaupt klären zu können, schauen wir uns erst mal an, wie eine klassische MMO-RPG Server Architektur aussieht und wie diese arbeitet.


Ein klassisches MMO-RPG hat eine grobe Serverarchitektur wie folgt:

Abbildung 1 MMO-RPG Architecture

Login System

Das Login System ist zumeist das erste System mit dem der Spieler in Verbindung tritt, dieses Authentifiziert den Spieler und gibt ihm meist die Auswahl, welchen Charakter er spielen und auf welchen Server er sich verbinden möchte.
Zusätzlich beinhaltet dieses System eine andere wichtige Aufgabe, es dient als Gatekeeper.
Für den Fall, dass eine große Menge Spieler zeitgleich auf den gleichen Server möchte, kann das Login System erst überprüfen, ob der Server dafür bereit ist. Falls dies nicht der Fall ist oder der Server tatsächlich vollständig gefüllt ist, können die Spieler in eine Warteliste gesteckt werden oder ihnen die Verbindung nicht erlaubt werden. Somit kann ein gutartiger DDOS abgewehrt werden.


Das Herzstück einer jeden MMO-RPG Architektur ist der Gameserver. Dieser übernimmt die Kommunikation mit den Spielern, verarbeitet die Aktionen der Spieler und deren Auswirkungen und hält den Stand der Welt.

Hierbei treffen wir nun auch auf einen der Hauptunterschiede zwischen klassischen ULS’s und einem MMO-RPG.
Ein klassisches ULS wie z.B. Twitter ist ein recht standardmäßiges Request-Response System auf extremer Größe. Ein Tweet wird nur abgerufen, wenn ein User danach fragt. Tweets werden nur verschickt, wenn Users diese erzeugen.

Dagegen ist ein MMO-RPG eine Welt, die dauerhaft simuliert wird. Auch ohne die Anfrage eines Users (Spielers) kann sich die Welt ändern und sich weiter bewegen, zum Beispiel ein Monster greift einen Spieler an, auch wenn dieser keine Aktion ausführt.
Gleichzeitig muss jede Aktion, die ein Spieler durchführt, evaluiert werden und auf der Welt ausgeführt werden. Jeder Spieler erfährt die Änderungen aller anderen und kann mit der Spielwelt interagieren.

Um dies zu bewerkstelligen, wird der Zustand der Welt im Gameserver simuliert, dieser hält die absolute „Wahrheit“ über die Welt und die mit ihm verbundenen Spieler. Dies wird dadurch realisiert, in dem die Welt auf dem Server im RAM simuliert wird, also „gespielt“ wird und alle Spieler nur Aktionen und Anfragen an den Server leiten. Regelmäßig werden diese Informationen dann an das Persistent-Data Storage System weiter geleitet, um die Änderungen festzuhalten.
Dennoch können bei einem Serverabsturz oder Serverfehler Informationen verloren gehen. Dieser Single-Point-of-Failure wird über verschiedene Systeme minimiert, bleibt aber bei dieser klassischen Architektur eine ständige Gefahr.

In nahezu jedem der großen MMO-RPGs wird der Zustand der Welt nicht auf einmal auf einer Instanz für alle Spieler gehalten, sondern in Shards aufgeteilt, die sich um eine begrenzte Menge an Spielern kümmern. Um Sharding in MMO-RPGs und die Umsetzung in Final Fantasy XIV geht es etwas weiter unten genauer.

Persistent-Data Storage System

Als letzten Teil der Architektur kommt der Persistent-Data Storage. Dieser kümmert sich darum, dass die Daten der Server persistent gespeichert werden und auch bei Server-Neustart wieder verfügbar sein. Dieses Storage System kann unterschiedlich aufgebaut sein und kann ebenfalls in Shards aufgeteilt sein.

So wird zum Beispiel in Final Fantasy XIV das Charakter Storage System pro Gameserver aufgeteilt, während das Charakter-Inventar und andere Inventar-Systeme unabhängig von diesen gespeichert sind.


Eine der wichtigsten Disziplinen in MMO-RPGs ist das Shrading.

Sharding ist nötig, um allen Spielern eine flüssiges und performantes Erlebnis zu bieten und überhaupt die Spielermenge zu verarbeiten.
Dieses Sharding wird in MMO-RPGs unterschiedlich gehandhabt. Um die Grundidee des Sharding zu erklären, sehen wir uns die Umsetzung von Final Fantasy XIV an.

Final Fantasy XIV hat zwei Hauptanteile an Sharding:

Hardware Sharding

Abbildung 2 Final Fantasy XIV Hardware Sharding [3]

Das Hardware Sharding ist in Abbildung 1 der Gameserver. Dieser ist nicht einfach ein Server für alle Spieler, sondern ist in verschiedene Layer aufgeteilt.

Final Fantasy XIV ist im Hardware Sharding folgend aufgebaut:

Regional Sharding

Final Fantasy XIV hat aktuell vier Data Center diese sind aufgeteilt nach Geografie:

  • North America Data Center
  • European Data Center
  • Oceanien Data Center
  • Japanese Data Center

Diese Data Center liegen (mittlerweile) in den jeweiligen Gebieten und haben damit die schnellste Verbindung für die jeweilige Region.

Logical Sharding

Jedes dieser Data Center ist wiederum in mehrere logische Bereiche unterteilt. Für das European Data Center sind das die beiden Logical Data Center:

  • Light
  • Chaos

Diese Logical Data Center besitzen die Aufgabe Spieler-Population aufzuteilen und Kontrolle über diese zu erhalten. Ebenfalls kann man davon ausgehen, dass jedes dieser Data-Center eine eigene Strom- und Wasserzufuhr haben, um Ausfallsicherheit zu gewährleisten.


Diese beiden Logical Data Center sind wiederum in jeweils acht Gameserver unterteilt.

Ein erstellter Charakter wird einem dieser Gameserver zugewiesen. Somit kann die Auslastung der einzelnen Server und deren Population kontrolliert werden. In Final Fantasy XIV kann zum Beispiel die Erstellung neuer Charaktere für einzelne Server gesperrt werden, wenn der Server mit Charakteren geflutet wird.

Diese Server sind in Final Fantasy XIV designt um bis zu 5000 gleichzeitige Verbindungen zu ermöglichen. Dies wurde den Spielern vor Augen geführt, als im Dezember 2021 mit Endwalker eine neue Erweiterung veröffentlicht wurde. Bei dieser Veröffentlichung gab es einen großen Andrang auf die Server, was zu Loginqueues von bis zu 4400 Spielern pro Server führte und Wartezeiten von bis zu acht Stunden mit sich brachte. [5]

Zusätzlich gibt es in Final Fantasy XIV auch noch Instanzsysteme, die unabhängig der Gameserver existieren. Dungeons, die man mit anderen Spielern bestreiten kann, werden auf eigenen Servern geladen und können von Spielern aller Gameserver des gleichen Logical Data Centers betreten werden, sodass ein Zusammenspiel zwischen Gameservern möglich ist.

Leider gibt es keine exakten Daten über die Hardware, die für Final Fantasy XIV verwendet wird, oder wie das Hardware Sharding für Final Fantasy XIV in Detail funktioniert.
Allerdings kann davon ausgegangen werden, dass ein Gameserver, entweder ein dedizierter Server Verbund ist, oder zumindest ein dedizierter Hardware Server, um die Spieler darauf zu verbinden.

Um dennoch ein paar Hardware Zahlen zu nennen:
In 2009 veröffentlichte Blizzard grobe Zahlen zu der Hardware, auf der World of Warcraft zu dieser Zeit lief. [2]

  • 13250 Server Blades
  • 75000 CPU Cores
  • 112.5 Terabyte Blade Ram

Man kann davon ausgehen, dass diese Zahlen sich bei Blizzard mittlerweile vervielfacht haben. Allerdings ist es gut möglich, dass wir bei Final Fantasy XIV von ungefähr diesen, beziehungsweise leicht höheren Spezifikationen ausgehen können, da Final Fantasy XIV dennoch eine geringere Spielerzahl als World of Warcraft besitzt.

Software Sharding / Instances

Nachdem wir nun auf einem Gameserver sind, wird das Spiel weiter aufgeteilt. Diese Shards ergeben sich meist aus dem Logischen Aufbau der Welt. Final Fantasy XIV, World of Warcraft und auch Guild Wars 2 teilen die Spielwelt in unterschiedliche Gebiete auf, jedes dieser Gebiete ist dann eine eigene Instanz die eine gewisse Menge an Spielern halten kann.

Diese Gebiete sind sowohl logisch-geografisch, so wie spiel-mechanisch voneinander getrennt. Der Gebietsübergang ist an festen Punkten vorgegeben und ist mit einem Shardübergang gekoppelt. Der Spieler bekommt währenddessen einen Ladebildschirm angezeigt.

Diese Instanzen der Spielwelt können auch unterschiedlich priorisiert werden, so ist zum Beispiel der Bereich Limsa Lominsa in Final Fantasy XIV ein Treffpunkt für viele Spieler und immer stark bevölkert. Diese Instanz hat mehr Ressourcen und kann mehr Spieler gleichzeitig halten als andere Shards des Spiels. Ebenso sind die Gebiete der jeweils neuen Erweiterung mit mehr Ressourcen ausgestattet, um die Spieler zu bedienen.

Diese Priorisierung könnte theoretisch auch dynamisch vorgenommen werden, allerdings nutzt Final Fantasy XIV diese Möglichkeit nicht.
Guild Wars 2 wiederum teilt die Spielwelt auch in verschiedene Gebietsshards auf, allerdings gibt es dort von jedem Gebiet wiederum auch mehrere Instanzen, diese werden dynamisch auf- und ab-gebaut, je nach benötigter Verfügbarkeit des Gebiets. Wenn sich eine der Instanzen langsam leert, werden die Spieler gebeten in eine belebtere Instanz des Gebietes zu wechseln, um den Abbau der Instanz zu beschleunigen und somit Ressourcen zu sparen.

Final Fantasy XIV Server Anecdote

Eines der Probleme, mit denen Final Fantasy XIV A Realm Reborn launchte, war der Standort des European Dat Centers. Das European Data Center befand sich nicht wie zu erwarten in Europa, sondern wurde in den USA gehostet. Dies führte dazu, dass europäische Spieler sehr hohen Latenzzeiten ausgesetzt waren. Dies gipfelte darin, dass einer der Boss-Kämpfe des Spiels „Titan Extrem“ für europäische Spieler fast unmöglich abzuschließen war und nur mit viel Glück beendet werden konnte.
Erst im Oktober 2015 wurde das European Data Center auch tatsächlich nach Europa verlegt und verbesserte so das Spielerlebnis für die europäischen Spieler. [4]

Daraus lernen wir: In MMO-RPGs mit zeitkritischem Gameplay sollten die Data Center und Server so nah wie möglich an den Spielern liegen, um ein gutes Spielerlebnis zu bieten. Ebenfalls sollten Namen wie European Data Center auch tatsächlich eine Bedeutung für die geografische Lage des Data Centers haben.

Fazit und Ausblick

Auch wenn klassische MMO-RPGs schon älter sind und Spiele wie New World auf Cloud-Systeme setzten, lohnt es sich weiterhin auf die alten Systeme zu blicken. Maximale Scalability ist zwar nicht die stärke dieser Architekturen, dennoch lösen sie ihr Problem mit einer Perfekt maßgeschneiderten Architektur. MMO-RPGs haben die Probleme von ULS schon für sich gelöst, bevor es den Begriff des Ultra-Largescale-Systems überhaupt gab.

Dennoch glaube ich, dass die Zeit dieser Technologie langsam vorbei ist.
Segmentierte Spielwelten, die auf einzelnen Gameservern laufen, sind aus der Mode gekommen. Man sieht am Beispiel von New World zumindest, dass es möglich ist große Spielerzahlen auch auf Cloudsystem in einer vollständig zusammen hängenden Welt darzustellen. Doch glaube ich, das klassische MMO-RPG-System auch zeigen, dass wenn man sich seiner Aufgabe genau bewusst ist, die Cloud nicht immer die Lösung ist, sondern auch die Umsetzung in einer eigenen Architektur effizient sein kann. Ähnliche genaue Lösungen sieht man beispielsweise bei Stack-Overflow.

Während Cloudlösungen in den meisten Fällen auf möglichst variablen Systemen laufen und eine große Palette an Funktonen bieten, maximale Scalability und Resizability bieten, fasziniert mich genau die Spezialisierung, mit der klassische MMO-RPGs die Probleme einer Concurrent Gameworld gelöst haben und bei der Serverarchitektur und Applikations- beziehungsweise Spiel-Design miteinander verzahnt wurden.







How to scale an IoT-Platform

Written by Marvin Blessing, Michael Partes, Frederik Omlor, Nikolai Thees, Jan Tille, Simon Janik, Daniel Heinemann – for System Engineering And Management


The aim of the project was to develop a system with which the power consumption of any socket in a household is determined and stored in real time and can be read out by users with the corresponding access data. The user of the system should be able to read out the data via a web application to which he can log in with an account. This should also ensure mobile access to the data. Furthermore, the measured data should be permanently stored in a database, so that users also have the option of viewing measured values over a longer period of time.

The measurement of power consumption should be made possible with a hardware element that is attached to the socket and writes the measured values to the database described.

Fig. 1: Basic system structure

The finished system includes a hardware element and forwards the measured current to a database via a message broker. In addition, the system includes a front-end (web page) through which a user can then query this data via an individual user account.

A more detailed description of the architecture can be found in the following chapter “Architecture”.

According to there were about 3.6 million homes in Germany that used energy management applications in 2020. For the year 2025 there is an estimate of about 15.3 million homes using energy management systems. Therefore, taking competition and market growth into account, it’s not unlikely that a system like the one we created could reach 2 million homes in the near future.


For the architecture of the project, we have to take a look at the system requirements which we defined based on the use case:

  • Read power data
  • Send power data from user to our system
  • Store power data
  • Store user data
  • Read power data based on the user
  • Visualize data for users
  • Monitoring and logging
  • (Authentification)

To implement these requirements, it is crucial to understand the needs of each requirement and figure out an efficient way to connect all the necessary components.

In the first step, we made a list of the technologies that we needed to implement those components:

  • Read power data: To measure the power data we need a Raspberry Pi that has access to the sockets of the user. On the Raspberry Pi is a Python script running that collects the power data.
  • Sending data from Raspberry Pi: To send the power data from the Raspberry Pi to our main system, we decided to use a message broker, since we have to be able to send a lot of data from many different users to our system at the same time.
  • Store power data: To store the power data we use a simple timeseries Database because all data points have a timestamp.
  • Store user data: For the user authentication we use a separate Database to store the user data.
  • Read power data based on the user: To access the stored data we decided to use multiple small services which are used to perform tasks on the databases. This includes an user authentication service which checks the correctness of the provided user data, as well as a read service and a write service to access the stored power data and write new power data to the timeseries database.
  • Visualize data for users: To visualize the data for the user we use a simple web app that uses the different services to access and present the power data to the user.
  • Monitoring and logging: To check the status of our system we use some self defined metrics that we can observe through dashboards.
  • (Authentification: We want to authenticate the user securely and therefore have planned an authentication service with Keycloak. However, this is not implemented at the current time.)

The connection of these components is shown in the following architecture diagram.

Fig. 2: The general architecture of the Energymonitor application

This diagram shows that each reading or writing access only occurs through a service defined by us. There is no direct access to a database, so that we have full control over the access options that we provide.
It also allows us to use those services as microservices. So each service is independent from the other ones and can be developed, tested and scaled on its own. The last aspect is especially important for the performance of our system. It gives us the option to only really scale up as needed. This means that if many users just want to read their data, only the read service needs to be scaled up, whereas the write service is not affected and we do not waste unnecessary resources on it.

This approach follows the CQRS (Command and Query Responsibility Segregation) pattern, which separates reading and writing data from a database. Interestingly, we didn’t know about this pattern when we implemented it, and through our own deliberations we realized the benefits of separating the services and only later discovered that this approach was already known as a pattern.

Scaling & Load Test

Estimations and predicted bottlenecks

To predict bottlenecks early and to estimate the overall requirements we created a scenario to check our resources and decisions against.

First of, the resources of our virtual machine are the following:

Fig. 3: Overview of the systems resources

We also created an overview of the data that would be sent throughout our system.

This helped us evaluate which components to choose and how to test our system in order to find bottlenecks.

Estimate users (households)2.000.000
Power values per user~ 30 values (constantly changing)
Data per user~ 300 bytes / min
Max. messages per minute1 / user / min = 2.000.000 / min 
Max. Throughput @ full utilization~ 600 MB / min

The systems user would generate the following data:

UserValue per time increment
1 user~ 157,68 MB / year
2 Mio User~ 315,36 TB / year
2 Mio User~ 86,4 Mrd messages / month

With these values in mind we could reevaluate our systems components and make an informed prediction about possible bottlenecks.

These are shown in the diagram below.

Fig. 4: Predicted bottlenecks in the systems components

To tackle the bottlenecks we listed some possible solutions for scaling and reducing the overproportional utilization of single components. Some of them included specific load balancing instances, database sharding and spreading load over time.


Before we conducted a load test we made sure that we were able to see the utilization of the critical components in our system. We therefore implemented the ‘TICK’ stack.

Telegraf → Data collecting agent

InfluxDB → Time series DB

Chronograf → Data visualization

Kapacitor → (Data processing) & alerting

Fig. 5: Monitoring inside Influx DB’s ‘Telegraf’

Fig. 6: Monitoring inside Influx DB’s ‘Telegraf’

Fig. 7: Monitoring inside Influx DB’s ‘Telegraf’

We created different dashboards to monitor the current utilization and throughput, as seen above. To connect our own services we implemented logging while using a shared data format which can be easily read by Telegraf. This allowed us to add most of our components to the monitoring system.

Load Test

Initially, we were using JSON as our data format. However, due to the relatively large size of JSON messages, we decided to switch to Protocol Buffers (protobuf) instead. This was due to the promising smaller transmitting size of protobuf messages.

In our protobuf message, we utilized a container object which contained multiple measurements. Each measurement contained the measurement name, device ID, energy measurement, and timestamp. This allowed us to effectively and efficiently transmit multiple measurements in a single message while keeping the overall size of the message to a minimum. By utilizing protobuf and optimizing our message format, we were able to improve the efficiency and effectiveness of our data transmission process.

Fig. 8 General data format used for the application

In order to determine the potential traffic requirements of our system, we conducted measurements to assess the size of our messages. We found that a container object containing eleven measurements was approximately 470 bytes, while a single measurement was around 37 bytes. We also measured the improvement in size comparing the container object in JSON and in protobuf. For JSON we measured that a container had the size of around 1075 bytes and thus our improvement in size was about 50%, which in network throughput can go a long way.

Using this information, we calculated the amount of traffic that would be required if we were to scale up to 2 million messages per minute, each containing a container object. Breaking it down to seconds would mean we had to scale up to 33 thousand messages per second. With this calculation, we were able to gain insight into the potential traffic demands that our system might face at scale. The expected amount of traffic required for our scale was expected to be around 14.95 MB/s, in regards to network traffic this would be around 119.6 Mbps. Knowing the network requirements and the shortcomings of slow home networks upload performance in Germany we were required to conduct load tests either with combined forces of several home networks or to test on the virtual machine itself or at least from within the same local network. We then tried the same machine approach.

Our general approach to load testing the system involved deploying it on our virtual machine and conducting performance tests. Initially, we tested the system as a whole but found that its performance was not meeting our expectations. To identify the root cause, we checked our monitoring and validated the performance of RabbitMQ both as a standalone component and as a part of our write service.

Fig. 9: Load testing the whole system and load testing the message broker

To conduct our load tests we used the RabbitMQ Performance Test Tool (perftest). Simulating the traffic from several Raspberry Pi instances from our system architecture.

RabbitMQ Standalone
Data470 bytesOur dataOur data
Send rate Messages/s~51.000~46.000~21.000
Receive rateMessages/s~50.000~45.000~20.000

The default PerfTest result for the RabbitMQ Standalone is higher than with our dataformat. This is probably due to the internal workings of the performance tool. As for the difference with RabbitMQ Standalone versus Standalone with manual ack there’s a large difference in over 50% performance loss. Going for throughput would mean that we would have to drop our data consistency.

Full Application (RabbitMQ, WriteService & InfluxDB)
DataOur dataOur dataOur dataOur data
Send rate Messages/s~10.000~20.000~13.000~20.000
Receive rateMessages/s~5.000~19.000~6.000~20.000

For our application we see an even further decrease in messages per second. Using auto ack and four receiving threads we only achieved half the performance of the receiver from the testing tool. Also the amount of threads used for our Go application did not seem to make any difference for the throughput. For scaling we thus should rather deal with missing data and interpolation techniques. 

Achieving only half the performance kept us wondering, which is why we took a look on our monitoring dashboards. At first glance either the WriteService or InfluxDB somehow became our bottleneck.

Fig. 10: InfluxDB writes during load test

The InfluxDB dashboard clearly shows a write peak of ~61.000 writes per seconds around the performance test.

Looking at the dashboard for our RabbitMQ we can see the performance around 20k messages per second as stated before. A slight difference is visible between ack and delivery rate of around 400 messages per second. Also the amount of acked messages did not match the messages sent through RabbitMQ. The amount of acked messages is equivalent to 11 * 20.000 ⇒ 220.000 rows per second, which our InfluxDB clearly didn’t reach.

Fig. 11: Queue deliver and ack rate during load test.

We could see that we also validated the performance of our write service and InfluxDB, which led us to determine that the write service and InfluxDB were slowing RabbitMQ down. We then conducted additional tests to validate the performance of the write service in isolation.

Fig. 12: Load testing the Timeseries DB component

Using a customized Go client we conducted a write test outside our application. Writing 2 million data points first single threaded and then multithreaded to check if any performance gain is reached. We reached similar speeds leading us to the conclusion that our Go client might not be the issue. InfluxDB now being our main suspect of performance loss. Due to the custom testing tool we also discovered that using the convenience of the Point data object from the InfluxDB Go client library actually cost us time. Internally of the Go library the Point data object was just converted to the InfluxDB line protocol format. Removing the transformation from protobuf to point but instead writing line protocol ourselves we increased the performance of our writes.

Despite our efforts even when matching the throughput of InfluxDB to our RabbitMQ we could not have accommodated our use case of 2 Million users with 30 devices per minute. Achieving 46.000 messages per second for 11 metrics we would expect around 15.000 for 30 metrics per second. Scaling this to a per minute metric would mean that we can support up to 900.000 households which is roughly the half of our goal. So either way more improvements would be required for RabbitMQ and InfluxDB to reach our target.


Our focus during system optimization was primarily on RabbitMQ, which resulted in neglecting the optimization of our writes to InfluxDB. As we were more accustomed to relational databases, we were unaware of the performance relevant configurations of InfluxDB. Our load tests revealed that the main issue was with our writes to the database, but we cannot be certain if we have optimized our single InfluxDB instance to its full potential. 

Given our VM constraints, it would have been better to place InfluxDB on a separate VM with an SSD and more RAM for better write performance. Additionally, we should have revisited our write design of the Go client, which we then could have verified with InfluxDBs own performance test tool called Inch. Moreover, we could have considered using multiple InfluxDB instances/sharding to further increase our write performance.

For RabbitMQ we would have required scaling as well, maxing our throughput for a single instance an improvement only could have been made with more instances and load balancing.

Unfortunately, most of these options were out of scope for our student project, but they can be explored with more time and computational resources.

Lessons Learned

Right from the beginning we were aware that running our observability solution on the same system we want to monitor is a bad idea. If there were a complete system outage there would be no way for us to see what happened as the monitoring would crash along with the system. 

We did it anyway because we were limited to our single VM on which we needed to deploy our entire application. We expected that we were not going to be able to monitor our system during network outages, deployments, etc. However, what we hadn’t fully considered is that this would also cause problems for us when trying to evaluate the performance of our services during the stress tests.

While performing a stress test, our Chronograf dashboards would first become slow and unresponsive because the system was under so much load. What we were able to see though was that the RabbitMQ and our write service would slowly eat up the entire system RAM, at which point the monitoring would only report back errors and Chronograf became completely unreachable. We did not anticipate that the other components would start stealing resources from our observability stack. Then again, part of that very stack, our InfluxDB, was being stress tested, which explains why the monitoring became slow to update. 

All this supports our plan to run the monitoring on and as a separate system in a market-ready version of the application.

Monitoring was also somewhat handy in finding bugs in our application: At one point our write service reported CPU usage of over 180 %. This was a clear indicator that there was a bug in our implementation. Thankfully though, it was just putting high demand on the CPU at that moment and hadn’t crashed our system yet. We rolled the service back to an older version where the bug hadn’t been observed, which gave us the time to find and fix the bug and quickly deploy the updated version without causing substantial disruption to the application. 

This, we think, is an excellent example of how monitoring paired with alerting can prevent outages or at least minimizes downtime. 

Development Process

Despite reaching a solution that works, there are quite a few things where we struggled along the way. Some of the lessons almost feel like they’re part of a book entitled “Wouldn’t it be cool… and other bad design approaches”. Making these mistakes can be embarrassing to admit, but struggles always bring an opportunity to learn with them. 

In retrospect, we lost ourselves in creating too much unnecessary functionality too early in the project. An example would be attempting to create a sharding resolver that lookups user tokens to distribute writes across different influx instances and buckets. Deep down we knew that it would probably be out of scope but we still fell victim to our curiosity. The proper way would have been to implement a minimal working prototype first, conduct a performance analysis, identify the bottleneck, and only then spend resources to resolve it.

While we recognize that anticipation of future problem sources is a valuable trait in developing software, not being able to resist these impulses massively harms overall productivity. In our case this meant we were constantly switching between problems, creating more and more zones of construction in the process. This made it harder to orient in the code and difficult to decide what to work on next.

What is so frustrating is that we are aware of this tendency and know the solution is to practice an iterative and incremental approach to development, yet we tend to repeat these rookie mistakes. Unfortunately, we realized too late that hexagonal architecture has a natural workflow to it that helps with the problem of getting lost. First, you start by getting a clear understanding of the problem domain. We recommend using to sketch out the components of the application and how they interact. Next, you define the application’s ports. Ports should be defined upfront, as they represent the key abstractions of the application and ensure that the application is designed to be technology-agnostic. The definition of port interfaces often happens in unison with the definition of domain objects, because domain objects inform the design of the interface and are often used as input and output parameters. Once ports are defined, develop the core business logic of the application. After that, it is a good practice to test the core business logic to validate it meets the functional requirements of the application. Testing the business logic before implementing the adapters also helps to ensure that any issues or bugs in the core functionality of the application are detected and resolved early in the development process.

Once the business logic is implemented and tested, proceed to implement the adapters that connect the application to the external environment. Test the adapters to ensure they conform to the ports and correctly transform data between the external environment and the business logic.

After adapters are implemented and tested, you can test the system as a whole, to ensure that all components work together as expected. This testing should include functional and integration testing. Last, refactor and continue to improve the design. In comparison, our unstructured and unfocused approach to implementation cost us valuable time.

Without following the workflow described above, you tend to push testing towards the end of the project. The combination of having acquired debt (need to re-factor code to make it easier to test) and a self-inflicted lack of time meant, we were not able to take advantage of hexagonal architecture offers in the domain of testing.

func WriteEvent(msg interface{}, target interface{}) error {
    // let the type checks begin …

func WriteWattage(m *domain.WattageMeasurement, token string) error {
    // no such problems

Fig. 13: Different approaches with very generic interfaces (top) and specific types (bottom)

Another problem we encountered was finding the right degree of abstraction. A generic solution is typically designed to be flexible and adaptable so that it can be used in a wide range of use cases without requiring significant modification. These adjectives sound highly desirable to the ears of a developer and, as a result, we wanted to build our code in a way that would allow completely changing out the message format, inject adapters via configuration instead of touching the source code, etc. It’s fair to say that my initial implementation was way too generic. More and more it felt like we were not building a solution to our specific use case, but almost a framework that could be used for similar problems. Eventually, we realized that generic doesn’t mean good. Adding lots of adaptability naturally adds more abstraction and indirection to the code. The most glaring indicators that something was going wrong were that our interfaces were inexpressive/vague, exhibited weak type safety, and forced us to write unnecessary code complexity to deal with that. When you build a highly adaptable system that can adapt to a whole bunch of cases that never happen, then all of that just ends up being a big waste of time. In hindsight, it is difficult to analyze what caused this obsession with developing something generic. Once we re-wrote everything to be as specific to our problem domain as possible, the code became expressive and readable, and the need for using empty interfaces as function parameters vanished. 

Identifying and improving bottlenecks

As software developers, we’ve all experienced the frustration of trying to identify and resolve bottlenecks in a system. We know that while it’s easy to detect the general location of a bottleneck, it can be hard to determine the actual issue. It’s also challenging to predict how software will perform with different hardware specifications or how all the components will interact with each other on a virtual machine. As we had no knowledge of the actual performance on our virtual machine we started to put everything on the machine and first tested the system as a whole. While the approach can work it is harder to determine the actual issue when a bottleneck seems to be prevalent. Also, using the numbers provided by the software vendors for the software solutions can help to get a rough estimate of the performance; it’s still different with each use case and current set up and can’t replace making your own measurements when going for performance.

One valuable lesson we’ve learned is to take a more methodical approach to identifying bottlenecks. Checking first if there is a load testing tool to produce load for a single component and then verifying the results with a custom implementation. For our approach as soon as we noticed a bottleneck we started to check each component individually on the target machine before adding additional components. This helped us isolate the source of the issue. Without our monitoring in place we would never have detected the bottleneck and we’ve thus realized that monitoring is crucial in detecting performance issues. By tracking performance metrics, we could identify areas of concern and take action to optimize processes such as unnecessary convenience data transformations and, depending on the use case, unrequired data consistency, which can significantly impact system performance.

In summary, while the process of identifying and resolving bottlenecks can be challenging, we’ve learned that taking a structured approach and paying close attention to performance metrics can help us identify and address issues efficiently.

AMD EPYC 9004 – a small scale supercomputer?

For a long time the server and desktop space was dominated by intel CPUs. AMD lacked severely behind the competition with its processors but changed everything up, when they launched their ZEN architecture processors in February 2017. Suddenly they started to compete on the consumer side of processors again and started to bring some competition to the market. But in the server space intel was still reigning supreme, which was about to change.

AMDs ZEN architecture was designed to be scalable and they did scale it a lot over time. While their EPYC server grade processors started with up to 32 cores in 2017, they doubled this in late 2018 to up to 64 cores with ZEN2, improved performance with ZEN3 in late 2019 and finally scaled it up to 96 cores in November 2022 with ZEN4 (7)(8). With this massive scaling of CPU cores they managed to outperform Intel chips and produce incredibly powerful single system servers.

AMDs 9004 series EPYC server CPUs brought some massive improvements over their previous generation by increasing the core count by up to 50% form an already staggering 64 cores, to a total of 96 cores per CPU (1). Additionally, the frequency of all cores increased, while the ‘infinity fabric’ which allows cross communication between the single cores improved as well (1). Additionally, the new series of CPUs switched from PCIe 4.0 to PCIe 5.0 and DDR4 to DDR5 memory, for an huge increase in I/O and read/write performance (1). But even if this performance wasn’t enough already, EPYC allows you to link two of their flagship CPUs together in a single motherboard, to act like a single 192 core CPU (1).

What would such a possible max spec system look like?

2x AMD EPYC 9654 for 192 cores, 384 threads per system. 128 PCIe gen 5 lanes, plus 6 PCIe gen 3 lanes per CPU, with either 48 or 64 lanes used to connect the CPUs for up to 160 gen 5 lanes and 12 gen 3 lanes. 12 DDR5 memory controllers per CPU to support 6 TB of memory each for a total of 12 TB DDR5 memory in one system (1)(10).

With all of this, the system is theoretically able to offer 10.752 teraflops of double precision float operations (5), 1.280 terabyte/s of PCIe 5.0 I/O and up to 921.6 gigabyte/s of DDR5 ram I/O (10).

But what exactly do these numbers mean? If we compare them to some supercomputers, that once managed to hold the world records, we can see that the fastest supercomputer of 2000 was the ‘ASCII White’ of the ‘Lawrence Livermore National Laboratory’, being able to calculate 7.2 teraflops (6). The maximized AMD EPYC system would be able to outperform this system, without using any GPUs for parallelized computing, which in the case of an RTX 4090 would add about 1.14 to 1.29 teraflops per card used (9).

In 2002 the ‘ASCII White’ was beaten by the ‘Earth Simulator’ by ‘JAMSTEC Earth Simulator Center’ in Japan (6). It managed to calculate 35.68 teraflops. Only by this supercomputer, which used a bigger budget then ‘ASCII White’ to be constructed, is our theoretical system surpassed.

But what can such performance even be used for?

Scientist at CERN had to previously rely on huge data centers, to be able to store the collision data, which gets generated and collected near instantly (3). Before the data is filtered it arrives at a data rate of 40 terabyte per second from the sensors and has to be stored somehow. To alleviate this dependency on data centers they upgraded their processing for the data detectors to servers running AMD EPYC 7742 processors with 64 cores and 128 PCIe 4.0 lanes (3). These powered four 200Gbit Mellanox networking cards, which received 800Gbit of data per server. If these would be upgraded to the new top of the line EPYC systems, they would be able to handle 10 of these network cards per server for a staggering 2 terabit of I/O, cutting the number of servers needed by 3/5th (4). This would result in huge power and cost savings, while also reducing the complexity of the entire system and making it less error prone. Considering that the previous upgrade to the EPYC 7742 systems already reduced their amount of servers needed by 1/3rd it would overall reduce the amount to 1/5th.

If we consider this power and cost saving we have to roughly estimate how much power and parts cost such an system would bring. Since the main costs are in the processors and ram required the other parts of the machine will be roughly estimated. An AMD EPYC 9654 has a listing price of 11,805 USD (4). DDR5 ram in 256GB must be estimated at about 1,000 USD since kits in this size are nearly impossible to find but scale almost linearly with size in cost (12). With all of this in mind, the cost is about 1000 USD * 24 ram sticks + 2 * 11805 = 47,610 USD or about 50,000 USD considering other parts.

Power usage can be estimated by up to 400W per CPU (11) and about 600W for cooling and ram each (11), for a grand total of about 1400W base power usage.

If we compare this to the previously mentioned supercomputers, we can see some huge differences. The ‘ASCII White’ had a construction cost of about 110 million USD and a power usage of 6MW (6). The ‘Earth Simulator’ had a construction cost of about 600 million USD and a power usage of about 12.8 MW (6). Therefore, it is quite fair to say, that the scientific community can hugely profit by the cost reduction that these systems offer, especially considering power usage.

But an comparison to some supercomputers from 20 years ago, isn’t to fair either. Even with the upcoming ZEN4c architecture, which is announced to improve core count to 128 cores (2), these systems can’t hold up to modern supercomputers. Especially not if these computers use exactly these processors to reach new highs of performance (5). The ‘Frontier’ supercomputer, finished in 2022, manages to calculate a staggering 1.102 exaflops, or 100,000 times the performance of our dual CPU system, while also consuming 21 MW (6). To say such a system is a true supercomputer is an overstatement but considering the workloads it can calculate it truly isn’t an ordinary server either and thus offer newfound possibilities for huge monolithic systems.


Modern application of Voice AI technology

Image of Voice AI header

With the advancement of technology and the gradually increasing use of artificial intelligence, new markets are developed. One of such is the market of Voice AI which became a commercial success with voice bots such as Alexa or Siri. They were mainly used as digital assistants who could answer questions, set reminders and they could generally tap into various databases to provide the aid and service that they were ask to provide. Although the popular use case seems to be primarily domestic, we have long since experienced other applications for Voice AI in areas such as UI speech control, voice recognition and replication and in use within entertainment media.

Faced with the ever-present but ever-growing interest in artificial intelligence which continue to further their influence on society, industry and the commercial landscape, my post will strive to demonstrate and inspect the technologies surrounding the application of Voice AI but also the concurrent obstacles it needs to overcome. However, before we can dive deeper into the topic, it is important to introduce the concept of Voice AI and its general technological workings.

Continue reading

AI and Scaling the Compute for the new Moore’s Law

AI and Scaling the Compute becomes more relevant as the strive for larger language models and general purpose AI continues. The future of the trend is unknown as the rate of doubling the compute outpaces Moore’s Law rate of every two year to a 3.4 month doubling.


AI models have been rapidly growing in complexity and sophistication, requiring increasingly powerful computing resources to train and operate effectively. This trend has led to a surge of interest in scaling compute for AI, with researchers exploring new hardware architectures and distributed computing strategies to push the limits of what is possible. Figure 1 depicts the scale of compute required to train language models for the last ten years.

Figure 1: Computation used to train notable artificial intelligence systems [1]

The evolution of AI models has been driven by advances in deep learning, which allows models to learn from vast amounts of data and make predictions or decisions with remarkable accuracy. However, the sheer size and complexity of these models require an unprecedented amount of compute power to train and operate, presenting significant challenges for hardware designers and data center operators. Despite these challenges, progress has been impressive, with new breakthroughs in hardware and software helping to unlock the full potential of AI. Specialized hardware, such as GPUs (Graphics Processing Units) and TPUs (Tensor Processing Units) have emerged as powerful tools for training AI models, while distributed computing architectures are being developed to allow multiple machines to work together seamlessly. As AI models continue to grow in complexity, the need for scalable and efficient compute resources will only continue to grow. Researchers and engineers will need to work together to develop new hardware and software solutions that can keep pace with the rapid evolution of AI, unlocking new possibilities for intelligent automation, predictive analytics and other transformative applications.

Requiring compute beyond Moore’s Law

As explained in [2] the training of AI systems can be categorized in two distinct Eras, the First Era and the Modern Era. The First Era of compute usage in training AI systems, starting with the perceptron, lasted from the 1950s to the late 2000s and relied on limited computational resources and simple algorithms. In contrast, the Modern Era began around 2012 with the rise of deep learning and the availability of powerful hardware such as GPUs and TPUs, allowing for the training of increasingly complex models with millions or even billions of parameters. [3] even suggests three Eras with the current one being the “Large Scale Era” starting with AlphaGo around 2016.

Figure 2: AlexNet to AlphaGo Zero: 300,000x increase in compute [2]

Increase in AI computation

Figure 2 depicts the increase in computational resources needed to train AI systems over time, which is evident by the rise of GPUs and TPUs and the transition from Moore’s Law’s 2-year doubling of compute to a 3.4-month doubling. This increase in compute demand is exemplified by the difference between AlexNet and AlphaGo Zero, where the latter requires 300,000 times more computational resources to train than the former.

With the rise of large language models like GPT, more recently known due to the publicly available ChatGPT, the question arose on how the trend on computing such models will continue. As seen in Figure 3 the amount of parameters to be learned are increasing rapidly and thus the amount of data and compute required for the models.

Figure 3: Amount of Parameters for Large Language Models [4]

The new Moore’s Law

Moore’s law is the observation that the number of transistors in a dense integrated circuit doubles about every two year [5]. As Moore’s Law has a physical constraint on how many transistors can be placed on an integrated circuits, which will cease to apply, a new trend in compute seems to emerge in the field of AI. As stated in [4] the increase of the size of the language model and in regard of the 3.4-month doubling time stated in [2] we seem to establish a new “Moore’s Law for AI” for compute, which can only be achieved with massive parallelization techniques.

Scaling AI computation

An earlier blogpost [6] already handled the explanation on how deep learning models can be parallelized with the different computation paradigms single instance single device (SISD), multi-instance single device (MISD), single-instance multi-device (SIMD) and multi-instance multi-device (MIMD). Furthermore, the concepts of Model and Data parallelization are explained in that post in more detail.

GPT-3 Example

If we take GPT-3 for example it was scaled up in several ways to enable it to handle its massive size and complexity. Here are some of the key techniques that were used [7]:

  1. Distributed training: GPT-3 was trained using a distributed training approach that involved multiple GPUs and TPUs working together in parallel. The training data was partitioned across the multiple devices and the model parameters were updated using a process called gradient descent, where each device calculated a portion of the gradient and then combined them to update the parameters.
  2. Model parallelism: Because GPT-3 has so many parameters (up to 175 billion), it was not possible to store the entire model on a single device. Instead, the model was split across multiple devices using a technique called model parallelism, where each device stores a portion of the model parameters and computes a portion of the model’s output.
  3. Pipeline parallelism: To further scale up training, GPT-3 also used a technique called pipeline parallelism, where the model is divided into multiple stages and each stage is run on a separate set of devices in parallel. This enables the model to handle much larger batch sizes and process more data in less time.
  4. Mixed precision training: GPT-3 used mixed precision training, which involves using both 16-bit and 32-bit floating-point numbers to represent the model parameters and compute gradients. This can significantly speed up training and reduce the memory requirements of the model.
  5. Adaptive optimization: Finally, GPT-3 used an adaptive optimization algorithm called AdamW that adjusts the learning rate and weight decay of the model dynamically during training. This helps to avoid overfitting and achieve better performance on the validation set.

In summary, the training of GPT-3 was scaled up using a combination of distributed training, model parallelism, pipeline parallelism, mixed precision training and adaptive optimization. These techniques allowed the model to handle its massive size and complexity.

Distributed training, but how?

In order to train a large AI model, scaling across multiple GPUs, TPUs, and machines is necessary. However, achieving this becomes more complex when using a compute cluster, as distributing tasks and aggregating results requires careful consideration of several points. Specifically, when training a large model at scale using a cluster of machines, the following
factors must be taken into account [8][9]:

  1. Communication overhead: Distributed training involves exchanging gradients and model updates between different machines, which can introduce significant communication overhead. Optimizing communication and reducing the frequency of communication can help reduce the overhead and speed up training.
  2. Load balancing: Distributing the workload across multiple machines requires careful load balancing to ensure that each machine has a similar workload. Imbalanced workloads can lead to underutilization of some machines and slower training overall.
  3. Fault tolerance: When using clusters of machines, it is important to consider fault tolerance, as failures in one or more machines can interrupt training. Strategies for fault tolerance include checkpointing, replication of model parameters, and the use of redundant compute nodes.
  4. Network topology: The topology of the network connecting the machines can affect the performance of distributed training. For example, using a network with high bandwidth and low latency can reduce communication overhead and speed up training.
  5. Scalability: The ability to scale up the number of machines used for training is important to accommodate largermodels anddatasets. Ensuringthatthetrainingprocess is scalablerequires careful consideration of the communication patterns and load balancing across a large number of machines.

The trend continues

Taking a look at an even larger language model, the Megatron-Turing NLG [10], we can see that the trend continues. Such large models therefore are required to train on large-scale infrastructure with special software and hardware design optimized for system throughput for large datasets. In [10] the tradeoffs for some techniques are mentioned. Only the combination of several techniques and the use of a supercomputer powered by 560 DGX 100 servers using each eight NVIDIA A100 80GB Tensor Core GPUs allowed NVIDIA to use scale up to thousand of GPUs and train the model in an acceptable time.

Conclusion and outlook

The trend for more compute is expected to continue as AI applications become more complex and require larger datasets and more sophisticated algorithms. To keep up with this demand, we can expect continued improvements in specialized hardware and software optimization techniques, such as neural architecture search, pruning and quantization. Scaling aspects of both software and hardware are critical to meet the increasing demand for computing power and to make AI more efficient and accessible to a wider range of applications.
In contrast to chasing even larger models another approach would be to focus more on specific tasks than general purpose models. As language models continue to grow in size, researchers are beginning to see diminishing returns in terms of their performance improvements. While larger language models have shown impressive capabilities in natural language processing tasks, the computational and financial resources required to train and run them have also increased exponentially. Therefore, [4] proposes a more practical approach which might be more cost and environment friendly than the next big general purpose AI.
As for now we can continue to observe large tech companies joining together for the next big AI model, using supercomputers, cloud infrastructure and every compute they have to build even more impressive AI and thus develop even more sophisticated software and hardware architectures to facilitate the massive amounts of data and computation required to train such models.


[1] OurWorld in Data. “Computation usedtotrain notable artificial intelligence systems”. In: (2023). URL:

[2] OpenAI. “AI and Compute”. In: (2018). URL:

[3] Jaime Sevilla et al. Compute Trends Across Three Eras of Machine Learning. 2022. arXiv: 2202.05924 [cs.LG].

[4] Julien Simon. “Large Language Models”. In: (2021). URL:

[5] Wikipedia. Moore’s Law. 2023. URL:

[6] Annika Strauß and Maximilian Kaiser. “An overview of Large Scale Deep Learning”. In: (2021). URL:

[7] Tom B. Brown et al. “Language Models are Few-Shot Learners”. In: CoRR abs/2005.14165 (2020).
arXiv: 2005.14165. URL:

[8] Martín Abadi et al. TensorFlow: A System for Large-Scale Machine Learning. 2016. URL:

[9] Henggang Cui, Gregory R. Ganger, and Phillip B. Gibbons. Scalable deep learning on distributed GPUs with a GPU-specialized parameter server. 2015. URL:

[10] Paresh Kharya and Ali Alvi. “Using DeepSpeed and Megatron to Train Megatron-Turing NLG 530B, the World’s Largest and Most Powerful Generative Language Model”. In: (2021). URL: