What every distributed application architects ought to know

Network is (un)reliable

2. Zero latency

3. Infinite Bandwidth

4. Secure network

5. Topology not changed


Why moving away from Monolith services to Microservices

  1. Scalability & Availability — two primary requirements of every distributed application. Imagine having one service being used twice as much as other services — the server is spending all its time processing that particular service request whilst neglecting all other lightweight services and being sluggish as a result of this. Instead, why not split that service and put it into a different server or container instance. Those services could be added into multiple container instances and load balancing can occur to improve the distribution of the workload. Lightweight servers can be hosted separately.
  2. Different technology stack Almost every company has systems build with different technologies and people with different skill sets. With the microservice architecture, you are not limited to hiring employees with a certain skill set only; instead, you can host different services built using different technologies that are able to seamlessly communicate with each other using this architecture.
  3. New features can be hosted as separate services on separate server with no downtown for existing services.

Microservice Myths:

Twelve Rules Application

  1. One codebase, with a single root repo, does not share code with another service.
  2. Explicitly declare and deploy dependent libraries with the service, that is, do not share deployment of a library with other services. Instead, treat the service as a unit. This allows you to test your code as a unit.
  3. Do not set any configurations in the code. Instead, externalize the configuration and read from there. Typically, this would apply to environment variables. Environment variables are supported by all platforms making them easy to configure and use.
  4. Handle the unresponsive service dependencies robustly and uniformly. Make no distinction between local and third-party services, and assume that they can be swapped in and out with no code change. This is also all about embracing failure, and actually treating failures as a way of life.
  5. Strictly separate build, release, and run stages.
  • Build. Build a version of the code repo and gather dependencies.
  • Release. Combine build step results with configuration to create an immutable release. This gives you the ability to reproduce the issue when someone says, “When I was running this service, I hit this bug.”
  • Run. Use the execution environment to run the service.
  1. A service is one or more stateless processes that shares nothing. It is generally a good practice to separate stateless and stateful services. A twelve-factor app concentrates on stateless services. Managing stateful services is a complex area and will be discussed in later sections.
  2. Expose the service on a port, and do not use other hosts (for example, a web host). Just have your service open a port to listen for requests, without relying on a host.
  3. Use processes for isolation, and use multiple processes for concurrency. Writing multithreaded services is difficult. Instead, write services single-threaded, and use multiple processes concurrently.
  4. Plan the processes so that they shut down gracefully and start fast. Always drain the request queue before shutting down. Try to not have long initialization sequences when services are starting up.
  5. Keep development, staging, and production environments similar. This makes it more likely to encounter a potential issue earlier in the life cycle.
  6. Treat logs as event streams. Don’t be concerned with routing or storing logs, and attempt to write to or manage log files. Write to the easiest place, stdout in an unbuffered way. Routing and archiving in production is the execution environment job, not the service’s. Keep the logging very simple in the application.
  7. Deploy and run the administrative or maintenance tasks as a separate process, and do not bundle with the service executable. Make changes in a predictable way through scripts. Do not change settings manually.
  • Simple to code, build, test, deploy, log, start up, and shut down.
  • Lightweight, with fewer dependencies (for example; OS, language, runtime, or libraries), this allowing them to run fast and use less memory.
  • Reproducible, giving similar results on the development environment as on the test,
  • staging, and production environments.

Messaging communication

  • Resource efficient: The client does not wait for the service reply, thus there are no blocked threads or long lived locks.
  • Resilient: The client and service instances can be taken down or move to another server without any effect because the messages will be kept by the messaging service.
  • Elastic: The queue length can be used to determine the need to scale the service up and down. If the queue length is increasing over time, the orchestrator can decide to increase the instance number. If it is getting smaller over time, the orchestrator can decrease the number of instances.


  • Rolling update in this case you partially update the service/application, so if there are 4 instance of application then you can take down 2 first and replace with new version so other 2 can keep application alive but it could hurt scale-ability and make application slow until you complete update.
  • Deleted & Update as name suggest, you first take down all instances of services and then in one go replace all instances. In this case down-time can happen and even it doesn’t guarantee if new version will work so if that doesn’t then you have to take that new version down and bring back so its quite risky but less costly.
  • Blue-green deployment it brings up new server where you can deploy new version and some of the traffic you can send to new server to assure if that new version is reliable and then you can switch off old server its obviously more costly deployment but more reliable and doesn’t hurt scale-ability

Backup and Restore

  • Document your backup and restore so in case of emergency if somebody has to do backup/restore of your application can do that
  • Validate your backup after making backup always test your backups as during time of disaster it could fail so you might not have any choice to bring it back



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
M Adnan A

M Adnan A


Love writing, learning, sharing and love being sarcastic :)