mirror of
https://github.com/ByteByteGoHq/system-design-101.git
synced 2026-04-17 22:57:25 -04:00
ee4b7305a2
This PR adds all the guides from [Visual Guides](https://bytebytego.com/guides/) section on bytebytego to the repository with proper links. - [x] Markdown files for guides and categories are placed inside `data/guides` and `data/categories` - [x] Guide links in readme are auto-generated using `scripts/readme.ts`. Everytime you run the script `npm run update-readme`, it reads the categories and guides from the above mentioned folders, generate production links for guides and categories and populate the table of content in the readme. This ensures that any future guides and categories will automatically get added to the readme. - [x] Sorting inside the readme matches the actual category and guides sorting on production
27 lines
1.7 KiB
Markdown
27 lines
1.7 KiB
Markdown
---
|
||
title: "Is Microservice Architecture the Silver Bullet?"
|
||
description: "Explore when microservices aren't the best choice for your architecture."
|
||
image: "https://assets.bytebytego.com/diagrams/0278-monolithic-arch-use-cases.jpg"
|
||
createdAt: "2024-02-24"
|
||
draft: false
|
||
categories:
|
||
- software-architecture
|
||
tags:
|
||
- "microservices"
|
||
- "architecture patterns"
|
||
---
|
||
|
||
The diagram above shows why **real-time gaming** and **low-latency trading** applications should not use microservice architecture.
|
||
|
||
|
||
|
||
There are some common features of these applications, which make them choose monolithic architecture:
|
||
|
||
* These applications are very **latency-sensitive**. For real-time gaming, the latency should be at the milli-second level; for low-latency trading, the latency should be at the micro-second level. We cannot separate the services into different processes because the network latency is unbearable.
|
||
|
||
* Microservice architecture is usually **stateless**, and the states are persisted in the database. Real-time gaming and low-latency trading need to **store the states in memory** for quick updates. For example, when a character is injured in a game, we don’t want to see the update 3 seconds later. This kind of user experience can kill a game.
|
||
|
||
* Real-time gaming and low-latency trading need to talk to the server in high frequency, and the requests need to go to the same running instance. So **web socket** connections and **sticky routing** are needed.
|
||
|
||
So microservice architecture is designed to solve problems for certain domains. We need to think about “why” when designing applications.
|