| title | impact | impactDescription | tags |
|---|---|---|---|
Avoid O(n²) Algorithms - Design for Enterprise Scale |
CRITICAL |
Prevents performance collapse at scale |
performance, algorithms, complexity, 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.com Engineering Blog