In the presentation tier of the website we want the ability to turn features on and off outside of release cycles.
I think we'll have around 150 switches.
Can you please outline a system that does that?
Please ask as many questions you need to clarify the requirements.
- What do the switches look like in code?
- Eg, data-type = boolean Vs. strings vs numbers??
- How does the rest of the application read the switches - Eg, an API, switch("foo").isOn
- What meta-data do we need to carry round with the switch? - Eg, name, description, owner, permissions
- Where would you store the switches?
- What if the backend failed? (Eg, they need to have a sensible default behaviour)
- How would someone operate a switch - ui vs. command line tool
- How would you prevent unauthorised usage? - infrastructure (ip address, pki), api based auth (google oauth), DIY user management
- How can both backend and frontend developers use the switches?
- Eg, Serialise to JS object of some sort.
- How can you notify people of switch changes.
- Audit logs, email, SNS
- If we had a 60 second cache on all of our switches (to ease load) then how can we make switch changes instantenous
- Eg, message queues to listen for switch changes
- (One answer is that the technical complexity of this system doesn't justify it's value)
- How would you test (unit) this?
- Social - how do you decide to turn off / on switches
- When the feature implementation is split across css/php/js how can we ensure we don't switch some parts of the system off (and not others).
- What classes of switches do you think are useful?
- Performance - eg, polling rate, cache-control
- Commercial - ads, tags
- APIs - read-only modes, broken
- Features - user facing
- How do people on developer machines use the switches?