Popular Posts

Spring boot Feature Toggle Server

Feature Toggles Specification

Feature Toggles Specification

Feature Toggles (often also referred to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code.


They fall into four categories

  • Release Toggles

  • Experimental Toggles

  • Operation Toggles

  • Permission Toggles

Release Toggles

Release Toggles allow incomplete and un-tested code paths to be shipped to production as latent code which may never be turned on.

       ​// Code that is under development but merged to master branch
       ​// This toggle can be enabled dev/qa but always disabled in prod

Experimental Toggles

Experiment Toggles are used to perform multivariate or A/B testing.

           ​// Write tactical flow logic
           ​// This may be enabled in prod but quickly trun off if the behaviour is not as expected
           ​// Write legacy flow logic

Operational Toggles

These flags are used to control operational aspects of our system’s behavior. We might introduce an Ops Toggle when rolling out a new feature which has unclear performance implications so that system operators can disable or degrade that feature quickly in production if needed.


        // send data to updraded db version
        // This is more of infrastucture related. ex: DB Switching
        // Most Ops Toggles will be relatively short-lived -
        // once confidence is gained in the operational aspects of a new feature the flag should be retired.

Permission Toggles

These flags are used to change the features or product experience that certain users receive. For example we may have a set of "premium" features which we only toggle on for our paying customers.

    if(toggleConfig.isEnabled(Toggle.TOGGLE_PII_MASKING_EXTERNAL_CHANNEL) && isExternalChannel(channelId)){

        // If the request comes from external channel. mask PII information
        // This is purely request based toggle

Toggle Management

Based on above discussion toggles divided into two base categories

  • Static Vs Dynamic toggles

  • Long-lived toggles vs transient toggles

Static Vs Dynamic toggles

Toggles which are making runtime routing decisions necessarily need more sophisticated Toggle Routers, along with more complex configuration for those routers.

For simple static routing decisions a toggle configuration can be a simple On or Off for each feature with a toggle router.

Experiment Toggle makes routing decisions dynamically for a given user.

Long-lived toggles vs transient toggles

Release Toggle which will be removed in a few days time then we can probably get away with a Toggle Point which does a simple if/else check on a Toggle Router.

If we’re creating a new Permissioning Toggle with Toggle Points which we expect to stick around for a very long time then we certainly don’t want to implement those Toggle Points by sprinkling if/else checks around indiscriminately. We’ll need to use more maintainable implementation techniques.

Toggle Router (Server)

Toggle Router which can be used to dynamically control which code path is live. There are many ways to implement a Toggle Router, varying from a simple in-memory store to a highly sophisticated distributed system with a fancy UI.


Toggle management follows client-server architecture.


Toggle server exposes simple REST APIs to manage toggles under its namespace.

namespace that represent common practice which is maintain toggles in a isolated and centralized location.

Ex: PROJECT-A, PROJECT-B are two namespaces.

Based on dynamism of toggles that expect huge load hence it should be more reactive to handle more requests.


Each individual service should uses client to read toggle state and maintain in it local cache, which is periodically read the latest configuration details from server.

Client can be implemented in two ways

  • Simple HttpClient which reads toggle states and keeps it in memory cache and reads information from server on scheduled base.

  • Distributed cache (redis/hazelcast) which will get latest data from server asynchronously via TCP/UDP protocol.


Toggle Server UI

Toggle server administrator UI helps ADMIN Team to quickly update toggle state from Web user interface. access to this UI is restricted based on the role of the users.

For example user with role ADMIN can able to edit toggle state. where as user with role DEVELOPER can able to only view the state of toggle.

Screen%2BShot%2B2020 07 19%2Bat%2B12.31.19%2BPM


Following CRUD operation can be performed on toggle server which is restricted based on following Authority levels.

  • ADMIN - Able change the toggle state, which will send email notification to all the members.

  • DEVELOPER - Able to view toggle state but don’t have permission to change the state.

  • QA - Able to view toggle state but don’t have permission to change the state.

Run as Docker container

If docker is installed in your machine you can run below command and point your browser to http://localhost:8080

tvajjala-mac:~ tvajjala$ docker run --rm -p 8080:8080 tvajjala/toggle-server

 ______               __      ____
/_  __/__  ___ ____ _/ /__   / __/__ _____  _____ ____
 / / / _ \/ _ `/ _ `/ / -_) _\ \/ -_) __/ |/ / -_) __/
/_/  \___/\_, /\_, /_/\__/ /___/\__/_/  |___/\__/_/

2020-01-19 16:25:34.245  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2020-01-19 16:25:34.251  INFO 1 --- [           main] com.tvajjala.toggles.Application         : Started Application in 4.751 seconds (JVM running for 5.572)

Toggle API

Applications can make call (Cached) REST API to Toggle-Server to fetch the state of toggle.

# curl http://localhost:8080/toggles/{TOGGLE_NAME}
tvajjala-mac:~ tvajjala$ curl http://localhost:8080/toggles/TOGGLE_PREMIUM_USER
  "id" : 2,
  "toggleName" : "TOGGLE_PREMIUM_USER",
  "lastModifiedOn" : "2020-01-19T16:25:33.059Z",
  "lastModifiedBy": "tvajjala",
  "enabled" : true,
  "channel" : "MOBILE",
  "toggleType" : "P" #Permission toggle

No comments:

Post a Comment