Overview
GoTours is a multinational travel booking platform that allows users to discover, book, and confirm tours, hotels, and travel experiences from multiple suppliers. As the platform continued growing, the product and engineering teams needed a safer way to release new modules, control access by user type, and test features without exposing unfinished functionality to every customer.
The main goal was to implement Policy-Based Module Access, also known as Feature Flags, so that GoTours could enable or disable features dynamically based on user roles, subscription plans, geography, partner type, environment, and business rules.
Instead of deploying code and immediately making the feature visible to all users, the team wanted a controlled system where new modules could be released gradually. This helped them reduce production risk, test features with selected users, and manage access without frequent code changes.
Quick Stats
- Feature rollback time: Reduced from 2–3 hours to under 5 minutes
- Release risk: Reduced through controlled rollout
- Internal testing speed: Improved by 40%
- Production incidents from new modules: Reduced by 35%
- Access control flexibility: Improved through role and policy-based rules
Challenges
Primary Challenge
GoTours was continuously adding new modules such as supplier dashboards, promotional pricing tools, loyalty features, beta booking workflows, and region-specific payment options. But every new feature release carried operational risk because once code was deployed, it became available to all users unless manually hidden through hardcoded conditions.
Core Challenges
1. All-or-Nothing Feature Releases
Before feature flags, most features were released in a direct deployment model. Once a module was pushed to production, it became active for all eligible users. If any issue appeared, the team had to either roll back the deployment or quickly apply a hotfix.
This was risky for a travel booking platform because even a small bug in payment, booking confirmation, or supplier pricing could directly affect revenue and customer trust.
2. Hardcoded Role-Based Logic
Some access rules were already present in the system, but they were mostly hardcoded inside the application. For example, certain modules were shown only to admin users, supplier users, or internal support teams.
The problem was that every access change required developer involvement. Even a simple request like “enable this dashboard only for selected suppliers” needed code modification, testing, and deployment.
3. Difficult Beta Testing
The product team wanted to test new features with a small group of users before releasing them widely. But the existing system did not support smooth beta rollouts.
For example, if GoTours wanted to test a new “Smart Tour Recommendation” module with only 5% of users in the UK region, it was difficult to manage without writing temporary logic in the codebase.
4. High Rollback Dependency on Deployment
If a feature caused an issue after release, the team had to depend on deployment rollback. This was not always ideal because rollback could also remove other fixes or improvements that were deployed in the same release.
The team needed the ability to turn off only the problematic feature while keeping the rest of the system running normally.
5. Lack of Business-Level Control
Business and product teams had to depend on engineering teams for every access change. This slowed down experiments, partner-specific feature enablement, and phased product launches.
The company needed a system where approved product owners could manage feature availability through a controlled admin interface instead of raising technical tickets every time.
Why This Mattered
For GoTours, feature access was not only a technical concern. It directly affected customer experience, supplier operations, revenue experiments, and platform stability. Without policy-based module access, every release carried unnecessary risk. The company needed a flexible system where features could be controlled independently from deployments.
Strategy
We designed and implemented a Policy-Based Feature Flag System that allowed GoTours to control module access dynamically without changing application code every time.
The system worked as a central decision layer between the user and the application modules. Whenever a user tried to access a feature, the application checked the feature flag service to decide whether the module should be visible, hidden, enabled, disabled, or partially available.
The strategy was not just to create simple on/off switches. The goal was to build a policy-driven access system that could support real-world business rules.
Solution Architecture (Layer-Based Breakdown)
1. Feature Flag Management Layer
The Feature Flag Management Layer worked as the central place where all feature flags were created, stored, and managed. Each flag contained important details such as feature name, feature key, module name, current status, target audience, rollout percentage, environment, start and end date, owner, and approval status.
For example, a flag like new_supplier_dashboard could be enabled only for selected suppliers, while loyalty_rewards_v2 could be released to only 10% of UK customers. Similarly, new_payment_gateway could remain enabled only in the staging environment for testing. This helped the team manage feature visibility easily without changing the code every time.
2. Policy Decision Layer
The Policy Decision Layer worked as the brain of the system because it checked all rules before allowing a user to access any module. The decision was based on different conditions such as user role, user type, country or region, supplier category, subscription plan, partner agreement, internal staff permissions, rollout percentage, device or platform, and environment.
For example, a policy could allow the Advanced Supplier Analytics module only for premium suppliers in Europe who were part of the beta program. This made feature access more flexible and controlled than basic role-based access control.
3. Application Integration Layer
The GoTours frontend and backend systems were both integrated with the feature flag service to ensure complete control over feature access. On the frontend, feature flags controlled things like menu visibility, button availability, dashboard widgets, beta banners, and experimental UI flows. On the backend, the same feature flag logic controlled API execution, booking workflow variations, payment method availability, supplier module permissions, and background job activation. This was important because hiding a feature only from the user interface is not enough for real security. Backend validation ensured that users could not access restricted modules directly through API calls.
4. Admin Control Panel
An internal admin panel was created for the product and operations teams to manage feature access more easily. Through this panel, authorized users could create new feature flags, enable or disable modules, select target users, configure rollout percentages, view flag status, check audit history, and approve or reject rollout requests. This reduced the dependency on engineering teams and made feature control much faster. However, the system was not open to everyone. Only approved product owners and admin users had permission to modify production feature flags.
5. Audit and Monitoring Layer
Every feature flag change was logged properly for security and accountability. The audit logs captured details such as who changed the flag, what was changed, the previous value, the new value, time of change, reason for change, and approval status. Along with this, monitoring dashboards were created to track feature usage, error rates after rollout, user adoption, API failures, conversion impact, and rollback events. This helped the team understand how each feature was performing and make rollout decisions based on real data instead of assumptions.
Technical Implementation
Feature Flag Service
A dedicated feature flag service was created and exposed through APIs. The application could call this service to check whether a feature should be available for a specific user.
The service was designed to respond quickly because feature checks happen frequently across the application.
Example decision flow:
- User logs into GoTours.
- Application loads user profile and permissions.
- Feature flag service checks active policies.
- Available modules are returned to frontend and backend.
- User only sees and accesses allowed modules.
Policy Rules Engine
A Policy Rules Engine was used to evaluate feature access dynamically based on configurable policies. Instead of hardcoding conditions like if user.role == supplier && country == UK directly inside the application code, these rules were stored and managed as flexible policies. This allowed the team to make non-code changes, such as enabling a feature only for UK users, allowing a module for selected supplier IDs, releasing a feature to 20% of logged-in customers, disabling a feature for mobile users, or enabling a feature only during campaign dates. This made the platform more adaptable to changing business requirements without needing frequent code changes or deployments.
Frontend Module Control
The frontend used feature flags to decide which modules should be shown in the interface.
For example:
- If supplier_analytics_v2 was enabled, the supplier dashboard showed the new analytics card.
- If it was disabled, users continued seeing the old dashboard.
- If the feature was in beta mode, only selected suppliers saw the beta version.
This helped the product team test new experiences without disturbing all users.
Backend Enforcement
Backend enforcement was one of the most important parts of the system because it protected the application beyond just hiding features from the frontend. Even if a user discovered a hidden route or API endpoint, the backend still checked the policy before processing the request. For example, a supplier without permission could not access /api/supplier/advanced-analytics. Even if the frontend menu was hidden, the backend would still return an access denied response when the policy conditions were not satisfied. This ensured that restricted modules could not be accessed directly and protected the system from unauthorized access.
Kill Switch Mechanism
A kill switch was added for high-risk modules such as payment, booking confirmation, promotional pricing, and supplier inventory updates. If any critical issue appeared, authorized admins could disable the feature instantly without waiting for a new deployment. This was especially useful during peak travel seasons when downtime or booking errors could cause major business impact.
Key Technical Decisions
Why Feature Flags Instead of Only Role-Based Access?
Role-based access control is useful, but it is not flexible enough for modern feature rollout. RBAC mainly answers who the user is, such as admin, supplier, customer, or internal staff. Feature flags go one step further and answer whether this user should access a specific feature right now under certain conditions. GoTours needed both systems together. RBAC controlled the general permissions, while feature flags controlled dynamic module availability, beta testing, gradual rollout, and temporary access.
Why Centralized Flag Management?
Centralized flag management was needed because GoTours had multiple modules and teams working on different parts of the platform. If every service managed feature flags separately, the system would become difficult to maintain and audit. A centralized system gave the team one source of truth for all feature decisions. It also ensured consistent policy decisions, easier auditing, faster rollback, and better governance across the whole platform.
Why Backend Validation Was Required?
Backend validation was required because hiding a feature only from the frontend does not provide real security. A user may still try to access a hidden feature directly through an API endpoint. Backend validation ensured that every restricted module was checked against the feature policy before processing the request. This made the feature flag system safe for real production use and protected GoTours from unauthorized access.
Results
After implementing Policy-Based Module Access, GoTours gained much better control over its release process and module accessibility.
The company could now deploy code without immediately exposing every feature to every user. This changed how product launches, beta testing, and emergency rollbacks were handled.
Business Impact
Policy-based module access helped GoTours achieve faster experimentation because product teams could test new modules with selected users without waiting for custom engineering changes every time. This made beta testing and product validation much smoother.
It also reduced release risk because new features were not released to all users at once. Instead, they were gradually rolled out in phases, which helped the team catch issues early before they affected the entire customer base.
GoTours also gained better partner-specific control. The platform could enable selected modules only for specific suppliers, premium partners, or regional business units based on business requirements.
During peak travel campaigns, the system improved operational confidence because high-risk features could be disabled instantly if any issue appeared. This allowed the team to protect bookings, payments, and user experience without waiting for a full deployment rollback.
Technical Performance
Before implementing policy-based module access, feature rollback usually took 2–3 hours. After the solution, rollback time was reduced to under 5 minutes.
Earlier, new modules were released with full deployment exposure, which means the feature could affect all users once deployed. After implementation, new modules were released through a controlled rollout process.
Beta testing was previously manual and developer-dependent. With the new system, beta testing became configurable through policies.
Access rules were earlier hardcoded inside the application. After the feature flag system was added, access rules were managed through the policy engine.
Before this solution, production incidents had a broad user impact. After controlled rollout, the impact was usually limited to the selected rollout group.
Business teams previously had a high dependency on developers for feature access changes. After implementation, this dependency was reduced because approved users could manage access through policies.
What Changed
Before this solution, GoTours treated deployment and release as almost the same thing. Once code was deployed, the feature was usually available.
After implementing feature flags, deployment and release became separate.
The team could deploy code safely, keep the feature hidden, test internally, release to beta users, monitor performance, and then expand access step-by-step.
This gave GoTours more control, lower risk, and better confidence in production changes.
Stakeholder Feedback
Future Outlook
AI-Based Rollout Decisions
In future, GoTours can use AI-driven analytics to recommend whether a feature should be expanded, paused, or rolled back based on error rates, user behavior, and conversion impact.
More Granular Policy Control
The system can be expanded to support more detailed access rules such as device type, customer lifetime value, booking history, or supplier performance category.
Integration with CI/CD Pipeline
Feature flags can be directly connected with deployment pipelines so that every new feature automatically starts in disabled or internal-only mode.
Self-Service Product Experimentation
Product managers can run A/B tests and controlled experiments without asking developers to manually create temporary access logic.
Key Learnings
- Policy-based module access is not only useful for hiding or showing features. It becomes a complete release control system when used properly.
- Feature flags reduce the fear of production deployment because teams can separate code deployment from feature release.
- Backend validation is very important because frontend-only feature hiding is not secure.
- Audit logs and approval workflows are necessary when business users can control production feature access.
- For large platforms like GoTours, feature flags improve speed, safety, and experimentation together.
FAQ
1. What is Policy-Based Module Access?
Policy-Based Module Access is a system where access to application modules is controlled through rules or policies. These rules can depend on user role, location, subscription plan, account type, environment, or rollout percentage. In simple words, it decides who can see or use a feature and under what condition.
2. How are Feature Flags different from normal permissions?
Normal permissions usually control broad access, such as whether a user is an admin, customer, supplier, or support user. Feature flags are more dynamic because they allow teams to enable or disable specific features for selected users, groups, regions, or traffic percentages without changing the code. So, permissions define user authority, while feature flags control feature availability.
3. Can Feature Flags replace Role-Based Access Control?
Feature flags should not completely replace role-based access control. RBAC is still needed for core security and permission structure, while feature flags should work with RBAC to manage dynamic releases, beta testing, module visibility, and business-level access. For example, RBAC may allow only supplier users to access supplier dashboards, but feature flags can decide which suppliers get the new dashboard version.
4. How does this help during production issues?
During production issues, the team can disable only the problematic feature using the feature flag system instead of rolling back the entire deployment. This allows other stable features to continue working normally. For high-risk modules like payments or bookings, a kill switch can instantly disable the affected feature and reduce business impact.
5. Is frontend feature hiding enough?
Frontend feature hiding is useful for user experience, but it is not enough for real security. The backend must also check the feature policy before processing any request, because users may still try to access restricted APIs directly. That is why GoTours implemented both frontend visibility checks and backend enforcement.
6. What kind of features are good candidates for feature flags?
Feature flags are useful for features that need controlled release, testing, or quick rollback. This includes new dashboards, beta modules, payment gateway changes, region-specific features, promotional pricing tools, experimental UI flows, supplier-specific capabilities, internal-only admin tools, and high-risk booking workflows.
7. What are the risks of using too many feature flags?
Using too many unmanaged feature flags can create confusion and technical debt. Old flags should be removed after the feature becomes stable, and every flag should have an owner, purpose, creation date, and cleanup plan. Without proper governance, feature flags can make the codebase harder to understand and maintain.
8. How long did the implementation take?
The implementation was completed in phases. The first phase focused on the core feature flag service and admin panel, the second phase integrated the system with frontend and backend modules, and the final phase added rollout percentage, audit logs, and monitoring dashboards. This phased approach helped GoTours adopt the system safely without disturbing existing production workflows.
