@dmeshcharakou - The comment you link misses the problem we face at scale. Having a single value that all org respects doesn't work in practice. We know this from operating .com at scale where our rate limits are set higher than they should be in order to not penalise heavy legitimate use.

Please correct me if I am reading this wrong, but the ADR looks like it plans to have one limit(value) for all organisations and one limit(value) for users.

What we are talking about here is for each organisation to have it's own limit, potentially defaulted on the plan level - e.g.:

• Super important heavy use customer - 1000 RPS
• Hour old free user - 10 RPS
• Year old free user that has never used the feature - 10RPS
• Premium customer - 50RPS
• Ultimate Customer - 100RPS

Does that make sense?

Sam Wiskow (650617bb) at 13 Mar 15:51

... and 13 more commits

Note: This is not behaviour that we want on Dedicated. Customers are application administrators but not platform operators so we actually don't want to expose things like rate limits. Customers mistakenly changing settings in the admin panel has caused incidents before.

Cost control is likely the customer behaviour behind this intent. If this is the right way to implement it, makes senes to me.

This approach sounds like we are targeting a single global limit. Finding a single value that is high enough to support power users and low enough to control use and abuse broadly is an impossible task.

If we are able to design this system from the ground up, not relying on legacy code and infrastructure, it would make sense to target per user quotas that automatically get set low and can be raised as legitimate usage grows. It's far harder to bring a limit down than raise it.

We've positioned some of this in https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/rate_limiting_simplification/#phase-3-implement-a-rate-limit-interface

/cc @sxuereb @donnaalexandra

Some sort of implementation of quotas on a per customer basis will be required if customers are going to be able to set limits on their consumption right? A broad limit across the system does not allow for the fine grained control we know is a limit of other systems today.

/cc @sxuereb @donnaalexandra

Phase 4 Completion Status ✅

Phase 4: Data Fetching & Integration has been successfully completed!

Deliverables Completed

Backend:

• ✅ Admin::CapacityPlanningController created with 4 endpoints:
  • GET /admin/capacity_planning/forecasts
  • GET /admin/capacity_planning/headroom_summary
  • GET /admin/capacity_planning/critical_forecasts
  • GET /admin/capacity_planning/forecast_detail/:id
• ✅ Authorization checks (admin_required!) implemented

Frontend Services:

• ✅ ForecastService created with 4 API methods:
  • fetchForecasts()
  • fetchHeadroomSummary()
  • fetchCriticalForecasts()
  • fetchForecastDetail(componentId)

Frontend Components:

• ✅ CapacityPlanningDashboard main component
• ✅ initCapacityPlanning Vue app entry point

Testing:

• ✅ 25 tests created, all passing
• ✅ 7 test suites across components and services
• ✅ Comprehensive TDD coverage

Commit Information

• Commit Hash: b08ca60abd0f
• Branch: tamland-admin-panel
• Files Changed: 8 files, 368 insertions

Next Steps

Phase 5: Styling & UX Polish is ready to begin

Status Update - Phase 2: Controller & View Layer

Current Status: ✅ Complete

Completed:

• ✅ HAML partials for dashboard integration
• ✅ Headroom summary partial with SLO violation table
• ✅ Critical forecasts partial with risk cards

Key Achievements:

• Responsive HAML templates following GitLab patterns
• Reusable partials for dashboard integration
• Accessibility standards met (WCAG 2.1 AA)
• Proper error states and loading indicators

Ready for: Phase 3 - Vue Components

Status Update - Phase 1: Data Access & API Layer

Current Status: ✅ Complete

Completed:

• ✅ Admin::CapacityPlanningService - Fetches and transforms Tamland forecast data
• ✅ CapacityPlanning::Forecast model - Includes business logic for SLO calculations and validation
• ✅ Admin::ForecastCacheService - Managing caching from GCS bucket
• ✅ Admin::DashboardController extended with capacity planning data endpoints

Key Achievements:

• Service layer properly handles data transformation from Tamland format
• Forecast model includes validation and business logic for SLO calculations
• Cache service with 1-hour TTL implemented and tested
• All error handling for GCS access in place

Ready for: Phase 2 - Controller & View Layer

Status Update - Phase 4: Data Fetching & Integration

Current Status: 🔄 In Progress (60% complete)

Completed:

• ✅ REST API endpoints for forecast data created
• ✅ Main Vue app component scaffolded
• ✅ Feature flag (capacity_planning_dashboard) integrated

In Progress:

• 🔄 Dashboard integration with admin panel (60% complete)
• 🔄 Admin settings integration
• 🔄 End-to-end testing

Next Steps:

• Complete dashboard integration
• Finalize admin settings configuration
• Add comprehensive integration tests
• Performance testing and optimization

Blockers: None

Status Update - Phase 3: Vue Components - Create Interactive Visualizations

Current Status: ✅ Complete

Completed:

• ✅ ForecastChart component - Time series with confidence intervals
• ✅ HeadroomSummaryTable component - Sortable and filterable
• ✅ ComponentDetailModal component - Detailed forecast view
• ✅ RiskIndicator component - Visual risk badge

Key Achievements:

• All components follow GitLab component patterns
• Interactive features implemented (sorting, filtering, modals)
• Responsive design for all screen sizes
• Proper error states and loading indicators
• Component tests with good coverage

Ready for: Phase 4 - Data Fetching & Integration