All of our services and applications were implemented using the twelve-factor app methodology for building software-as-a-service apps.
One codebase tracked in revision control, many deploys
Explicitly declare and isolate dependencies
Store config in the environment
Treat backing services as attached resources
Strictly separate build and run stages
Execute the app as one or more stateless processes
Export services via port binding
Scale out via the process model
Maximize robustness with fast startup and graceful shutdown
Keep development, staging, and production as similar as possible
Treat logs as event streams
Run admin/management tasks as one-off processes
Each component must be responsible for a specific feature or a functionality or aggregation of cohesive functionality. We chose a microservices / event-based architecture where each component is encapsulated and does exactly one job.
Performance is measured by throughput, response time (eg. 2500 TPS -transactions per second). The performance requirements must be available in the beginning of the design phase itself. So, appropriate technology and design decisions must be taken, to avoid re-work in the later stage.
We choose Golang (for most use-cases) to reach exatcly this goal. Our components are designed to be highly performant and extermely lightweight build.
The golden rule for availability says, anticipate failures and design accordingly so that the systems will be available for 99.999% (Five Nines). It means the system can go down only for a 5.5 minutes for an entire year. The cluster model is used to support high availability, where it suggests having group of services run in Active-Active mode or Active-Standby model.
Microservices must be scale-able both horizontally and vertically. Being horizontally scale-able, we can have multiple instances of components to increase the performance of the system.