Files
calendar/agents/rules/performance-scheduling-complexity.md
T
Benny JooGitHubbenny@cal.com <sldisek783@gmail.com>Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
ab21c7f805 refactor: Cal.diy (#28903)
* feat: Cal.diy — community-driven MIT-licensed fork of Cal.com

This squashed commit contains all Cal.diy changes applied on top of calcom/cal.com main:

- Rebrand Cal.com to Cal.diy across the entire codebase
- Remove Enterprise Edition (EE) features, license checks, and AGPL restrictions
- Switch license from AGPL-3.0 to MIT
- Remove docs/ directory (migrated to Nextra at cal.diy)
- Remove dead code: org tests, EE tips, platform nav, premium username, SAML/SSO, etc.
- Clean up .env.example for self-hosted Cal.diy
- Update Docker image references to calcom/cal.diy
- Update README, CONTRIBUTING.md, and issue templates for Cal.diy community fork
- Add PR welcome bot for Cal.diy contributors
- Fix API v2 breaking changes oasdiff ignore entries
- Replace Blacksmith CI runners with default GitHub Actions

3893 files changed, 20789 insertions(+), 411020 deletions(-)

Co-Authored-By: benny@cal.com <sldisek783@gmail.com>

* refactor: remove org-specific /organizations/:orgId endpoints from API v2 atoms controllers (#1701)

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* fix: revert Cal.diy Inc to Cal.com, Inc. in license files, copyright notices, and package metadata (#1702)

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

* rip out org related comments in api v2

---------

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
2026-04-15 09:52:36 -03:00

59 lines
2.5 KiB
Markdown

---
title: Handle NP-Hard Scheduling Problems Carefully
impact: HIGH
impactDescription: Prevents exponential blowup in scheduling operations
tags: performance, scheduling, algorithms, np-hard
---
## Handle NP-Hard Scheduling Problems Carefully
**Impact: HIGH**
Scheduling problems are fundamentally NP-hard. This means that as the number of constraints, participants, or time slots grows, the computational complexity can explode exponentially. Most optimal scheduling algorithms have worst-case exponential time complexity, making algorithm choice absolutely critical.
**Real-world implications:**
- Finding the optimal meeting time for 10 people across 3 time zones with individual availability constraints is computationally expensive
- Adding conflict detection, buffers, and other options amplifies the problem
- Poor algorithm choices that work fine for small teams become completely unusable for large organizations
- What takes milliseconds for 5 users might take many seconds for organizations
**Strategies for managing NP-hard complexity:**
```typescript
// Use approximation algorithms
async function findMeetingTime(participants: User[], duration: number) {
// Find "good enough" solution quickly rather than perfect solution slowly
const approximateSlots = await findApproximateAvailability(participants, {
maxIterations: 1000,
timeout: 500, // ms
});
return approximateSlots[0]; // Return first good-enough option
}
// Implement aggressive caching
const cachedAvailability = new LRUCache<string, Availability>({
max: 10000,
ttl: 1000 * 60 * 5, // 5 minutes
});
// Pre-compute common scenarios during off-peak hours
async function precomputeTeamAvailability(teamId: number) {
// Run during low-traffic periods
const team = await teamRepository.findById(teamId);
const availability = await computeTeamAvailability(team);
await cache.set(`team:${teamId}:availability`, availability);
}
```
**Key strategies:**
- Use approximation algorithms that find "good enough" solutions quickly
- Implement aggressive caching of computed schedules and availability
- Pre-compute common scenarios during off-peak hours
- Break large scheduling problems into smaller, more manageable chunks
- Set reasonable timeout limits and fallback to simpler algorithms when needed
This is why performance isn't just a nice-to-have in scheduling software. It's the foundation that determines whether your system can scale to enterprise needs.
Reference: [Cal.diy Engineering Blog](https://cal.com/blog/engineering-in-2026-and-beyond)