From given features I identified three groups of usages:

• AUTHORING-SERVICE: Survey authoring module that is going to be used by survey creators. Expected number of module users (request per sec) is in reasonable order of magnitude. This module will also provide questions and answers at survey beginning. Features in this module:

  • add/edit/delete questions, answers

  • read a list of all questions

  • read a question with all answers

• RESULTCAPTURE-SERVICE: Survey result capture module that is going accept and store actual answers. Expected number of requests in this module is much higher than in the previous case. Features in this module:

  • respond to a survey

• ANALYTICS-SERVICE: Analytics module will provide different statistical aggregations based on actual answers. This module is going to be used by first group of users or/and survey owners. This group of users is also much smaller than second one. Features in this module:

  • read the result for a particular question showing the total number of responses and distribution among the possible answers in percent.

From all above I can make assumption that each module will have different scaling needs so decided to design them as separate services.

In addition to mentioned services two more technical services are going to be used:

• GATEWAY-SERVICE: for dynamic request routing, security, monitoring…​

• REGISTRY-SERVICE: for service discovery

Each service will have its own mongodb instance. Exception from this is first iteration of ANALYTICS-SERVICE which is going to pull data from other two services on request. In future iterations I can implement it in more robust and scalable way to be able to support big and fast data analytics in realtime (Spark, Kafka …​???) …​

JSON data format over http rest endpoints is going to be used for communication between client and server, as well as for inter-service communication. Use synchronous service communication because of better cloud tools support at the moment (spring streams cloud or spring 5 reactive is still immature)

Use Netflix Eureka for service discovery and Ribbon for client side load balancing and Zuul for request routing. For auto scaling, self healing I’ll relay on cloud provider platform such is Kubernetes. Hystrix is responsible for circuit breaker functionality.

To be able to support smooth API api evolution versioning is going to be in place from the start. Versioning method of choice is use of Accept header in each request Accept=application/vnd.survey-1.0+json