# cluster\_constraints

## Summary

A ClusterConstraint describes a filtering of the Instances in a Cluster based on their Metadata. Instances in the keyed cluster with a superset of the specified Metadata will be included. The Weight of the ClusterConstraint is used to inform selection of one ClusterConstraint over another.

### Example object

```javascript
{
    "constraint_key": "constraint-key-1",
    "cluster_key": "passthrough-cluster-3",
    "metadata": null,
    "properties": null,
    "response_data": {},
    "weight": 1
}
```

### Fields

#### `constraint_key`

A string value to uniquely identify this constraint in the API.

#### `cluster_key`

The key of the [cluster](https://greymatter.gitbook.io/grey-matter-documentation/1.7-beta/reference/api/fabric-api/cluster) that matching requests will be sent to.

#### `metadata`

Array of `{"key": "", "value": }` pairs that mush match on the intended cluster.

#### `properties`

This field has no effect.

#### `response_data`

Array of [Response data](https://greymatter.gitbook.io/grey-matter-documentation/1.7-beta/reference/api/fabric-api/route/response_data)

#### `weight`

This field determines how traffic is distributed among the members of the constraint, but it has different interpretations depending on if it's used in `light` or `dark` constraints.

**light**

When used in the `light` constraint, it will be the relative weight expressed as an integer. This is because `light` traffic must always represent 100%, so any weights are totaled and divided among the members to determining fractional routing.

**dark**

When used in the `dark` constraint, it will be the percentage of traffic expressed as an integer. This is because `dark` traffic does not need to equal 100%; one shadow cluster may get 10% of traffic and another 40%, or whatever spread makes sense to the application.