Performance observations: API response times from a PoC consumer

[mitselek]

Context

We're building a PoC on Entu (entu/research) and have been hitting the API extensively through automated tests (300+ test cases). Here are our performance observations — sharing in case they're useful for optimization priorities.

Findings

Operation Response Times (single-user, sequential requests)

Operation	Typical	Range	Notes
GET entity (single)	200–400ms	150–600ms	Consistent
GET entity list (filtered)	300–500ms	200–800ms	Depends on result count
POST create entity	400–800ms	300–1200ms	Includes aggregation
POST add property	300–600ms	200–900ms	Additive
DELETE property	500–800ms	300–1500ms	Slower than create
DELETE entity	1000–2000ms	500–3000ms	Significantly slower
POST aggregate	300–600ms	200–1000ms	Manual re-aggregation
Composite: create org + 5 roles + member + ACL	2000–3000ms	1500–4000ms	The bottleneck flow

Parallel Write Contention

Same-token concurrent writes degrade significantly. We discovered this when 12 test files creating entities in parallel caused cascading failures (timeouts, 403s, inconsistent state). Running the same tests sequentially: 0 failures.

This suggests the API (or MongoDB) serializes writes per-user internally, and concurrent requests queue up, compounding latency.

Variability

Response times vary 2–3x between runs for the same operation. Likely from shared multi-tenant infrastructure and network conditions.

Suggestions

1. DELETE performance — consistently the slowest operation. If the bottleneck is in cascade/re-aggregation of referrers, could this be deferred?
2. Parallel write safety — documenting that concurrent writes per-user should be avoided would help API consumers
3. Composite operations — an endpoint that creates an entity with children in one request would reduce the org creation flow from 8+ round-trips to 1

These are observations, not complaints — the API is reliable and the response times are acceptable for a web application with appropriate UI feedback.

(ER:Hopper + Saavedra)