#Issue80
3 posts

Do you have too many microservices? - 5 design attributes that can help

When you are developing microservices, ensure that each service relies on its own underlying data stores. If multiple services reference the same table in a DB, there is a great chance that your DB is a source of coupling. You must avoid such coupling.
Read more

Do you have too many microservices? - 5 design attributes that can help

  • When you are developing microservices, ensure that each service relies on its own underlying data stores. If multiple services reference the same table in a DB, there is a great chance that your DB is a source of coupling. You must avoid such coupling.
  • You should try to minimise the number of database tables a microservice uses.
  • At the onset, be clear about whether a service needs to be stateful or stateless.
  • Understand the system-wide relationships of a microservice with other services and what impact does non-availability of a particular microservice will have on the system.
  • Design your service to be the single source of truth for something in your system.

Full post here, 9 mins read

Unique benefits of using GraphQL in microservices

The data structure in GraphQL allows for well-defined & delineated data ownership for each request. You can have great control over the data loading process and therefore control how data is transferred in a very granular way.
Read more

Unique benefits of using GraphQL in microservices

  • The data structure in GraphQL allows for well-defined & delineated data ownership for each request.
  • You can have great control over the data loading process and therefore control how data is transferred in a very granular way.
  • As GraphQL allows for request bundles composed of many requested resources, it can leverage a sort of parallel execution for data requests. This allows a single request to fulfill the requirements that would otherwise have been through multiple requests to multiple services over multiple servers.
  • GraphQL can budget requests, allows the server to prioritize requests and grant them where appropriate, and reduces timed out requests in the long run.
  • It saves ave processor time and effort because it utilizes Object Identifiers to cache often-requested data.

Full post here, 8 mins read

Walking the wire: Mastering the four decisions in microservices architecture

There should be no shared databases. If updates happen only in one microservice, you can use message queues to share data. If updates happen in two services, either merge the two services or use transactions.
Read more

Walking the wire: Mastering the four decisions in microservices architecture

  • There should be no shared databases. If updates happen only in one microservice, you can use message queues to share data. If updates happen in two services, either merge the two services or use transactions.
  • Handle microservice security by using a token-based approach. It pushes the authentication to the client and does access control at microservice level simplifying dependencies.
  • Handle microservice composition by driving flow from client browser, through orchestration or through a centralised server that runs the workflow.
  • Avoid a spaghetti of dependencies by having a proper & detailed plan of how & when which microservices should call each other. Understand the impact of such an invocation on the overall performance of the system.

Full post here, 9 mins read