Title: 🐢 getTeamSchedule Extremely Slow on v5.x.x (~20s) vs v4.x.x – Causes 502 Errors

Issue Summary

After upgrading from Cal.com v4.x.x to v5.x.x, the endpoint /api/trpc/highPerf/getTeamSchedule has experienced a major performance regression. It now takes around 20 seconds to respond when loading team schedules (specifically for our Booker team use case), compared to sub-second performance in v4.x.x.

This delay not only impacts the user experience by making the team availability UI unusable, but also frequently results in 502 Bad Gateway errors under moderate to heavy load.

Upon investigation, the main bottlenecks seem to originate from inefficient queries in the code path—especially:

• EventTypeRepository.findForSlots → making N+1 queries and taking over 7 seconds.
• Several other functions in the same resolver stack are taking 5+ seconds each.

These delays accumulate, making the endpoint unusably slow in production scenarios.

Steps to Reproduce

1. Use Cal.com v5.x.x (issue does not exist in v4.x.x).
2. Set up a team booking configuration (e.g., multiple users in the Booker team).
3. Navigate to a scheduling page that relies on getTeamSchedule.
4. Observe latency and possible 502 errors.

Why it's a bug:
This endpoint was designed as a high-performance route and worked efficiently in v4.x.x. In v5.x.x, it's failing to meet performance expectations and introduces infrastructure-level failures.

Actual Results

• The getTeamSchedule endpoint takes ~20 seconds to return data.
• Booker UI becomes unusable while loading availability.
• In many cases, the server returns a 502 Bad Gateway error due to timeout or resource exhaustion.

Expected Results

• Endpoint should return in ~2-3 second (as it did in v4.x.x).
• Booker UI should render availability quickly.
• No backend gateway errors should occur.

Technical details

• Cal.com Version: v5.x.x
• Node.js version: 18.0 (Docker container)
• Database: PostgreSQL 16.3 (AWS RDS)
• Deployment: AWS ECS
• Browser/Client: N/A
• Debugging Tools: N/A

Identified performance bottlenecks:

• EventTypeRepository.findForSlots: N+1 query pattern → ~7s delay
• Other resolver-level functions → ≥5s each

You can reproduce this reliably using the Booker team config under /api/trpc/highPerf/getTeamSchedule.

Evidence

• Tested across multiple environments: dev, staging, and production.
• Profiling and logs show N+1 query patterns and long response durations.
• 502s observed in server logs with correlation to getTeamSchedule requests.