Hi everyone, I’m currently evaluating SpiceDB for our production workload and running some performance benchmarks, but I’m seeing higher latency than expected. I’d appreciate your insight on our configuration and whether our use case is a good fit for ReBAC. Current Issue In our test environment (100 concurrent requests, almost no cache hits), it takes about 12–13 seconds for all requests to complete. - Infrastructure: - SpiceDB: 2 x ECS Tasks (2 vCPU, 4GB RAM each) - Datastore: Aurora Serverless v2 (PostgreSQL 17) - Observation: Aurora seems to have plenty of headroom and connection pool, so I suspect the bottleneck might be on the ECS/SpiceDB side or our configuration (we've tried adjusting dispatch-concurrency-limit). Use Case & Requirements We want to achieve a p95/max latency of under 3s (ideally mode/p50 around 1s) under the following peak load: - Peak Load: ~600 concurrent users (3 teams of 200 users) performing "List Content" actions simultaneously. - Heavy Operations: LookupResources or CheckBulkPermissions for ~500 resources per request. - Consistency: Using minimize_latency (expecting to leverage dispatch caching). Questions 1. Given the load of 600 concurrent users checking permissions for 500 resources each, what would be a reasonable starting point for ECS Task specs (CPU/RAM) and replica count? 2. In our schema (see below), we use an intersection (&) for member_view. We understand this can be expensive, but we've kept it for safety. Does this significantly impact performance at this scale, or should we prioritize refactoring this to improve latency? 3. Are there any alternative approaches or specific flags we should look into for this level of concurrency? Thank you in advance for your help!