> ## Documentation Index
> Fetch the complete documentation index at: https://docs.revoengine.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Design coordination keys

> Choose keys for shared capacity, duplicate business operations and cached data.

For an invoice integration, choose the key according to the resource you are protecting. `warehouse_sync` can group competing Jobs. `invoice:invoice-1:issue:v1` identifies one effect even if that invoice is retried later. Keep those identities separate.

| Mechanism | Key identifies | Reuse rule |
| - | - | - |
| Job concurrency | A shared capacity bucket | All Jobs competing for that resource use the same configured key. |
| `api.concurrencyLimit()` | A capacity bucket for explicit low-code admission | Independent executions may share it while holding separate slots. |
| Idempotency | One intended business effect | Retries of that same effect reuse the same key. |
| Cache | A reusable answer | Include every input that can change the answer. |
| Widget cell ID | One UI element | Keep stable across renders; it is not a distributed coordination key. |

## Explore the behavior

### Same key, shared capacity

`·   per key`

Next step

**O** Orders**I** InvoicesDashed boxes are available slots

**/ slots in use** ·  waiting ·  finished

<details open>
  <summary>Change key or limit</summary>

  Limit per key
  Reset
</details>

Illustration of ordinary admission. A waiting Job has no slot and has not failed. The example steps do not specify timing or execution order.

## Capacity keys

A shared external warehouse account may require `warehouse_sync` on every related Job template. If each template chooses its own name, their limits add together at the external service.

Job-template keys accept letters, numbers, underscores and hyphens. They are literal configured strings. Do not copy an expression such as `event.data.customerId` from a different workflow product into this field.

For dynamic per-customer admission inside a bounded Component, derive a validated key in code and use [explicit low-code concurrency](https://docs.revoengine.com/patterns/low-code-concurrency.md). This controls the admitted section; it does not change the Job template's dispatch bucket.

## Idempotency keys

An invoice-issue operation needs a key tied to the invoice and operation version, such as `invoice:invoice-1:issue:v1`. A fresh random key for every retry defeats duplicate protection. A key shared by all invoices prevents unrelated work.

Define how long a retry may arrive before choosing expiry. Keep durable business evidence after the admission key expires. See [idempotency](https://docs.revoengine.com/patterns/idempotency.md).

## Cache keys

Include the customer scope, filters, relevant revision and time window when they affect the result. Avoid secret values and personal payloads in keys. Expiry means a cached answer may be absent; it does not mean a business effect has been reversed.

See [Database Cache](https://docs.revoengine.com/operate/database-cache.md) for cache operations and [retry recovery](https://docs.revoengine.com/patterns/retry-and-uncertainty.md) for uncertain outcomes.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.