ab21c7f805
* 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>
2.2 KiB
2.2 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Avoid O(n²) Algorithms - Design for Enterprise Scale | CRITICAL | Prevents performance collapse at scale | performance, algorithms, complexity, scale |
Avoid O(n²) Algorithms - Design for Enterprise Scale
Impact: CRITICAL
We build for large organizations and teams. What works fine with 10 users or 50 records can collapse under the weight of enterprise scale. Performance is not something we optimize later. It's something we build correctly from the start.
When building features, always ask: "How does this behave with 1,000 users? 10,000 records? 100,000 operations?"
Common O(n²) patterns to avoid:
- Nested array iterations (
.mapinside.map,.forEachinside.forEach) - Array methods like
.some,.find, or.filterinside loops or callbacks - Checking every item against every other item without optimization
- Chained filters or nested mapping over large lists
Incorrect (O(n²) - exponential slowdown):
// Bad: O(n²) - checks every slot against every busy time
const available = availableSlots.filter(slot => {
return !busyTimes.some(busy => checkOverlap(slot, busy));
});
// For 100 slots and 50 busy periods: 5,000 checks
// For 500 slots and 200 busy periods: 100,000 checks (20x increase!)
Correct (O(n log n) - scales gracefully):
// Good: O(n log n) - sort once, break early
const sortedBusy = [...busyTimes].sort((a, b) => a.start - b.start);
const available = availableSlots.filter(slot => {
// Binary search or early exit
const index = binarySearch(sortedBusy, slot.start);
return !hasOverlapAt(sortedBusy, index, slot);
});
Better data structures and algorithms:
- Sorting + early exit: Sort data once, break out of loops when remaining items won't match
- Binary search: Use for lookups in sorted arrays instead of linear scans
- Two-pointer techniques: For merging or intersecting sorted sequences
- Hash maps/sets: Use for O(1) lookups instead of
.findor.includeson arrays - Interval trees: For scheduling, availability, and range queries
Reference: Cal.diy Engineering Blog