Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
# 5 Things You Should Keep in Mind When Deploying to a Clustered Environment

Let’s be honest — moving from a single server to a cluster sounds simple on paper.
You just add a few more machines, right?
In practice, it’s the moment when small architectural mistakes start to grow legs.
Below are a few things that experienced engineers usually double-check before pressing that “Deploy” button.

---

## 1️⃣ Managing State the Right Way

Each request in a cluster might hit a different machine.
If your application keeps user sessions or cache in memory, that data probably won’t exist on the next node.
That’s why many teams decide to push state out of the app itself.

![Stateless vs Stateful](stateless.png)

**A few real-world tips:**
- Keep sessions in **Redis** or something similar instead of local memory.
- Design endpoints so they don’t rely on earlier requests.
- Don’t assume the same server will handle two requests in a row — it rarely does.

---

## 2️⃣ Shared Files and Where to Put Them

Uploading files to local disk? That’s going to hurt in a cluster.
Other nodes can’t reach those files, and you’ll spend hours wondering why images disappear.

![Shared Storage](shared.png)

**Better habits:**
- Push uploads to **S3**, **Azure Blob**, or **Google Cloud Storage**.
- Send logs to a shared location instead of writing to local files.
- Keep environment configs in a central place so each node starts with the same settings.

---

## 3️⃣ Database Connections Aren’t Free

Every node opens its own database connections.
Ten nodes with twenty connections each — that’s already two hundred open sessions.
The database might not love that.

![Database Connections](database.png)

**What helps:**
- Put a cap on your connection pools.
- Avoid keeping transactions open for too long.
- Tune indexes and queries before scaling horizontally.

---

## 4️⃣ Logging and Observability Matter More Than You Think

When something breaks in a distributed system, it’s never obvious which server was responsible.
That’s why observability isn’t optional anymore.

![Observability](logging.png)

**Consider this:**
- Stream logs to **ELK**, **Datadog**, or **Grafana Loki**.
- Add a **trace ID** to every incoming request and propagate it across services.
- Watch key metrics with **Prometheus** and visualize them in Grafana dashboards.

---

## 5️⃣ Background Jobs and Message Queues

If more than one node runs the same job, you might process the same data twice — or delete something by mistake.
You don’t want that kind of excitement in production.

![Background Jobs](background.png)

**A few precautions:**
- Use a **distributed lock** or **leader election** system.
- Make jobs **idempotent**, so running them twice doesn’t break data.
- Centralize queue consumers or use a proper task scheduler.

---

## Wrapping Up

Deploying to a cluster isn’t only about scaling up — it’s about staying stable when you do.
Systems that handle state, logging, and background work correctly tend to age gracefully.
Everything else eventually learns the hard way.

> A cluster doesn’t fix design flaws — it magnifies them.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# 5 Things You Should Keep in Mind When Deploying to a Clustered Environment

Let’s be honest — moving from a single server to a cluster sounds simple on paper.
You just add a few more machines, right?
In practice, it’s the moment when small architectural mistakes start to grow legs.
Below are a few things that experienced engineers usually double-check before pressing that “Deploy” button.

---

## 1️⃣ Managing State the Right Way
---

## 2️⃣ Shared Files and Where to Put Them
---

## 3️⃣ Database Connections Aren’t Free
---

## 4️⃣ Logging and Observability Matter More Than You Think
---

## 5️⃣ Background Jobs and Message Queues
---

![all](all.png)

👉 Read the full guide here: [5 Things You Should Keep in Mind When Deploying to a Clustered Environment](https://abp.io/community/articles/)
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.