# Policies & Choosing the Right One

## Policies

When creating a Placement Group, you select a **policy** that determines how Neevcloud places your servers on physical hosts. There are four policies available.

### Affinity

**All instances on the same physical host**

All servers in this group are guaranteed to run on the same physical machine. Traffic between them never leaves the host, giving you the lowest possible network latency.

**Best for:**

* Primary + replica database setups requiring ultra-fast replication
* App server + cache server pairs that need sub-millisecond communication
* Tightly coupled services that exchange large volumes of internal data

{% hint style="danger" %}
**Trade-off:** If the physical host fails, all servers in the group go offline together. Do not use Affinity if uptime is more important than performance.
{% endhint %}

### Anti-Affinity

**Each instance on a different physical host**

Every server in this group is placed on a separate physical machine. If one host fails, only the server on that host is affected — the rest continue running normally.

**Best for:**

* Web server replicas sitting behind a load balancer
* Application nodes where uptime is critical
* Any workload where you cannot afford multiple servers failing at the same time

{% hint style="warning" %}
**Trade-off:** Server creation will fail with an error if Neevcloud does not have enough distinct physical hosts available to satisfy the rule.
{% endhint %}

### Soft Affinity

**Best-effort same host — no error if not possible**

Neevcloud will try to place all servers on the same host. If that is not possible (for example, the preferred host is at full capacity), the server will still be created on a different host — no failure, no error.

**Best for:**

* Development and staging environments where co-location is preferred but not critical
* Situations where you want Affinity behaviour without the risk of blocked launches
* Workloads that can tolerate occasional cross-host placement

{% hint style="info" %}
**Trade-off:** You do not get a strict guarantee that all servers land on the same host. Use Affinity if co-location is mandatory.
{% endhint %}

### Soft Anti-Affinity

**Best-effort different hosts — no error if not possible**

Neevcloud will try to place each server on a separate host. If there are not enough distinct hosts available, the server still launches — it may share a host with another group member, but will not fail.

**Best for:**

* Production workloads where availability matters but guaranteed separation is not mandatory
* Auto-scaling scenarios where you may launch more servers than available hosts
* The safest general-purpose policy for most production deployments

{% hint style="info" %}
**Trade-off:** You do not get a strict guarantee that each server is on a different host. Use Anti-Affinity if strict separation is required.
{% endhint %}

***

### Policy Comparison

| Policy             | Placement Goal                | On Insufficient Hosts   | Risk                                        |
| ------------------ | ----------------------------- | ----------------------- | ------------------------------------------- |
| Affinity           | Same physical host            | ❌ Server creation fails | All servers fail together if host goes down |
| Anti-Affinity      | Different physical hosts      | ❌ Server creation fails | Launch blocked if hosts unavailable         |
| Soft Affinity      | Same host (best effort)       | ✅ Server still launches | Occasional cross-host placement             |
| Soft Anti-Affinity | Different hosts (best effort) | ✅ Server still launches | Occasional shared-host placement            |

***

### Choosing the Right Policy

```
Do you need servers placed TOGETHER for low latency?
│
├── YES
│    └── Can you accept a launch failure if the host is full?
│         ├── YES → Use Affinity
│         └── NO  → Use Soft Affinity
│
└── NO — I need servers SEPARATED for high availability
     └── Can you accept a launch failure if hosts are unavailable?
          ├── YES → Use Anti-Affinity
          └── NO  → Use Soft Anti-Affinity  ← Recommended for most production use
```

***

### Common Use Cases

| Scenario                                | Recommended Policy                  |
| --------------------------------------- | ----------------------------------- |
| MySQL / PostgreSQL primary + replica    | Affinity                            |
| Redis + App server on same host         | Affinity                            |
| Web server fleet behind a load balancer | Anti-Affinity                       |
| Kubernetes worker nodes                 | Anti-Affinity or Soft Anti-Affinity |
| Dev / staging environment servers       | Soft Affinity                       |
| Production auto-scaling groups          | Soft Anti-Affinity                  |
| Kafka / Cassandra / HDFS cluster nodes  | Anti-Affinity or Soft Anti-Affinity |