ClickTime
Resource Planning Architecture
Re-engineered ClickTime's resource planning and time tracking platform to support enterprise-scale deployments with 100,000+ concurrent users, real-time reporting, and predictive resource allocation.

The Structural Challenge
ClickTime's time tracking and resource planning platform served thousands of enterprises, but the original architecture — a Ruby on Rails monolith with a jQuery frontend — was straining under the load of its largest clients. Organizations with 5,000+ employees experienced report generation times exceeding 45 seconds, and the single-tenant database architecture meant that large-client operations degraded performance for all users on the shared infrastructure.
The reporting engine, which was the core value proposition for enterprise clients, ran complex aggregation queries directly against the production database. During month-end reporting periods, these queries consumed 80% of database CPU capacity, causing cascading latency increases across the entire platform.
Enterprise clients were churning at a 15% annual rate, with exit interviews consistently citing performance issues and the lack of real-time data visibility as primary reasons for switching to competitors.
The Systems Architecture & Solution
We implemented a CQRS architecture that separates the write path (time entries, project assignments, resource allocations) from the read path (reporting, dashboards, analytics). Write operations flow through a normalized PostgreSQL database optimized for transactional integrity, while a materialized view layer in DynamoDB serves pre-computed report data with single-digit millisecond latency.
The reporting engine was rebuilt as a serverless pipeline on AWS Lambda, triggered by change data capture events from the primary database. When a time entry is submitted, a cascade of Lambda functions updates all dependent materialized views — project totals, department rollups, budget utilization — within seconds rather than requiring batch recomputation.
We introduced a multi-tenant data partitioning strategy that isolates large enterprise clients into dedicated database partitions while maintaining a shared infrastructure for smaller accounts. This eliminated the noisy neighbor problem where large-client operations impacted platform-wide performance.
Architecture Decisions
CQRS with event-driven materialized views for sub-100ms report queries
Serverless reporting pipeline processing changes in real-time via CDC triggers
Multi-tenant partitioning isolating enterprise workloads from shared infrastructure
GraphQL API layer with DataLoader batching eliminating N+1 query patterns
The Measurable Enterprise Impact
Report generation times dropped from 45 seconds to under 5 seconds for the largest enterprise clients — an 89% improvement that transformed reporting from a scheduled batch activity into an interactive, real-time capability. Project managers began using the reporting dashboard as a live operational tool rather than a periodic review mechanism.
Enterprise client retention improved by 23 percentage points as the performance improvements and real-time capabilities addressed the primary churn drivers. Several clients who had been evaluating competitor platforms renewed multi-year contracts based on the platform improvements.
89% faster
Report Speed
Enterprise report generation reduced from 45s to under 5s
180ms p95
API Latency
Consistent performance across all client sizes and peak periods
+23%
Client Retention
Enterprise segment retention improvement eliminating performance-based churn
-78%
Database Load
Production database freed from reporting queries through CQRS separation