Skip to main content
Software Engineering

Return to Answer

deleted 2 characters in body
Source Link
Phil S
Phil S
  • 209
  • 1
  • 3

Deal with potential problems in a logical order, avoiding the temptation to prematurely optimise.

  • Write your microservice application to be scalable. The most important part of this is that it is stateless. You should be able to spin up / shut down individual instances of the service without issue.

  • If you ever need to scale up your applicationservice due to demand, your code is not a blocker, and it should be relatively straight forward.

  • If you need shared state between containersservice instances, use a shared cache, such as Redis.

  • Scaling your database is a different issue. It makes sense in 90% of cases to have a single database that all copies of your applicationservice to connect to, until your load causes problems.

  • Horizontally scaling databases do exist (or correctly utilising a no-SQL db such as Cosmos, if you can properly design around the partition keys), but they tend to be more complex and expensive.

  • Other options do exist if you reach this point. E.g. would you start to have a database per tenant, per service, instead of a single database for all?

Deal with potential problems in a logical order, avoiding the temptation to prematurely optimise.

  • Write your microservice application to be scalable. The most important part of this is that it is stateless. You should be able to spin up / shut down individual instances of the service without issue.

  • If you ever need to scale up your application due to demand, your code is not a blocker, and it should be relatively straight forward.

  • If you need shared state between containers, use a shared cache, such as Redis.

  • Scaling your database is a different issue. It makes sense in 90% of cases to have a single database that all copies of your application connect to, until your load causes problems.

  • Horizontally databases do exist (or correctly utilising a no-SQL db such as Cosmos, if you can properly design around the partition keys), but they tend to be more complex and expensive.

  • Other options do exist if you reach this point. E.g. would you start to have a database per tenant, per service, instead of a single database for all?

Deal with potential problems in a logical order, avoiding the temptation to prematurely optimise.

  • Write your microservice to be scalable. The most important part of this is that it is stateless. You should be able to spin up / shut down individual instances of the service without issue.

  • If you ever need to scale up your service due to demand, your code is not a blocker, and it should be relatively straight forward.

  • If you need shared state between service instances, use a shared cache, such as Redis.

  • Scaling your database is a different issue. It makes sense in 90% of cases to have a single database that all copies of your service to connect to, until your load causes problems.

  • Horizontally scaling databases do exist (or correctly utilising a no-SQL db such as Cosmos, if you can properly design around the partition keys), but they tend to be more complex and expensive.

  • Other options do exist if you reach this point. E.g. would you start to have a database per tenant, per service, instead of a single database for all?

Source Link
Phil S
Phil S
  • 209
  • 1
  • 3

Deal with potential problems in a logical order, avoiding the temptation to prematurely optimise.

  • Write your microservice application to be scalable. The most important part of this is that it is stateless. You should be able to spin up / shut down individual instances of the service without issue.

  • If you ever need to scale up your application due to demand, your code is not a blocker, and it should be relatively straight forward.

  • If you need shared state between containers, use a shared cache, such as Redis.

  • Scaling your database is a different issue. It makes sense in 90% of cases to have a single database that all copies of your application connect to, until your load causes problems.

  • Horizontally databases do exist (or correctly utilising a no-SQL db such as Cosmos, if you can properly design around the partition keys), but they tend to be more complex and expensive.

  • Other options do exist if you reach this point. E.g. would you start to have a database per tenant, per service, instead of a single database for all?