Guides
Start typing to search…

Limits & Performance

This page summarizes practical limits, scalability expectations, and performance patterns when working with Operations.

Keep in mind

  • Large payloads are expected: thousands of lines and accounts per Operation.
  • All list endpoints are paginated and should be combined with filters.
  • Keep heavy diffs and searches server-side when possible. Avoid fetching entire Operations on the client for comparisons.

🔢 Capacity overview

  • Product variants per Operation: up to ~5000 lines observed in production scenarios.
  • Accounts per Operation: up to ~1500 attached accounts.
  • Concurrent active Operations: several hundreds in parallel.

These figures are indicative guidelines to size UI and batch workflows.

graph LR
  Q[Need to update many items?] -->|Yes| B[Use batch endpoints<br>PUT/DELETE /v1/operations/:id/lines<br>POST/DELETE /v1/operations/:id/accounts]
  Q -->|No| S[Use single resource calls]
  B --> TIP[Split very large payloads<br>keep admin UX snappy]
  S --> TIP

  classDef total fill:#e8f1ff,stroke:#2f6feb,stroke-width:2px,color:#0b3d91;
  classDef diff fill:#fff4e5,stroke:#f59e0b,stroke-width:2px,color:#7a3e00;
  classDef resp fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;

  class B diff; class TIP resp;
  style Q rx:8,ry:8; style B rx:8,ry:8; style S rx:8,ry:8; style TIP rx:8,ry:8

🧭 Use pagination and filters

Endpoints are paginated. Combine pagination with filters to reduce payload sizes and render times.

  • Operations list (admin) GET /v1/operations Filters available: status, operationId, operationName.
  • Lines GET /v1/operations/{id}/lines Filters available: variantExternalId, variantName.
  • Accounts (PRIVATE) GET /v1/operations/{id}/accounts Filters available: operationStatus, accountName, accountId, userId, email.
graph LR
  L[List page] --> R[GET list<br>with filters]
  R --> P{Page has next token}
  P -- Yes --> N[GET next page]
  P -- No  --> D[Done]

  %% ---------- Styles ----------
  classDef total fill:#e8f1ff,stroke:#2f6feb,stroke-width:2px,color:#0b3d91;
  classDef diff fill:#fff4e5,stroke:#f59e0b,stroke-width:2px,color:#7a3e00;
  classDef acct fill:#f5e9ff,stroke:#8a2be2,stroke-width:2px,color:#3b0764;
  classDef view fill:#ede9fe,stroke:#7c3aed,stroke-width:1.5px,color:#1e1b4b;
  classDef union fill:#e9d5ff,stroke:#6d28d9,stroke-width:1.5px,color:#3b0764;
  classDef visible fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
  classDef op fill:#e0f7fa,stroke:#06b6d4,stroke-width:2px,color:#065f46;
  classDef inter fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;
  classDef resp fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;

  class R diff;
  class P diff;
  class N visible;
  class D resp;

  style L rx:8,ry:8
  style R rx:8,ry:8
  style P rx:8,ry:8
  style N rx:8,ry:8
  style D rx:8,ry:8

In the UI, prefer incremental loading with a visible page size, and enable search on the server. For tables of 1k rows or more, add virtualized scrolling on the client.

🧩 Batch operations

Use batch endpoints to reduce roundtrips:

  • Lines: PUT /v1/operations/{id}/lines updates multiple lines in one call.
  • Lines deletion: DELETE /v1/operations/{id}/lines accepts a list of product variant ids.
  • Accounts: POST and DELETE /v1/operations/{id}/accounts accept lists.

Keep payloads reasonably sized to maintain snappy admin UX. Split very large batches if needed.

🔒 Concurrency, locking and safety

  • Lines and accounts are editable only in DRAFT. This protects carts and orders created from ACTIVE Operations.
  • Avoid changing dates in ACTIVE unless required for the campaign.
  • Deleting an Operation is blocked if any cart or order is linked.

🧠 Frontend UX tips

  • Use skeletons or loading states while fetching pages.
  • Sort by code or name to help operators find Operations quickly.
  • Add client-side selection buffers when building partial carts orders from large Operations.
  • Use locales efficiently: request a single locale for front DTOs and keep admin DTOs multilingual when editing copy.

🧪 Heavy comparisons and reporting

If you need to compare an order with an Operation, prefer a server-driven approach rather than downloading all lines to the browser for large Operations. Reuse admin filters to scope the comparison set when possible.

🔗 API quicklinks

Required headers (Admin)

  • dj-client: OPERATOR (or ACCOUNT for authorized admin actions)
  • dj-api-key: your key
  • dj-store, dj-store-view (optional; store scoping)
  • locale (optional; localized fields)

High-volume list endpoints (use filters + pagination)

Batch endpoints (reduce round-trips)

Concurrency & safety (what impacts performance)

  • Lines and account attachments are editable only in DRAFT to protect carts/orders once the Operation is ACTIVE/INACTIVE.
  • Avoid heavy client-side diffs; prefer server-side comparisons for large Operations.

Deletion constraints

Tip: For very large datasets, apply filters first, then page through results. Use sort to stabilize pagination order, and keep batch payloads to a practical size to maintain a responsive admin UX.

Updated 23 days ago