System design for modern web apps - Microservices architecture
1 Answer


Broadly, web apps have two requirements:

  1. frontend request handling [server]
  2. async background jobs (celery+rabbitmq / sqs+lambda / gcs+cloud functions) [serverless architecture]


Microservices should do a single job and ideally have their own data source.

Let's take an example:

Service Name Input Output Data Store
Login Service username  + password session token mysql server
Streaming Service movie id + authentication from Login Service data transfer connection to your device big data system
Recommendation Service user model movie names mongodb
Monthly subscription Service user plan true or false mysql server
(User can be duplicated from Login datastore but carefully)

Problems with Monolithic system:

  1. Need of specialized systems is not suitable in monolithic architecture
  2. Entire system goes down with single failure (high cohesion)

Benefits of Microservices:

  1. Different configuration for different systems is possible
  2. Low cohesion between systems enable scaling

Microservices should talk to each other. There are various ways in which this can happen

  1. REST APIs
  2. Pub/Sub (publisher + subscriber)
  3. Push based communication


[GET POST PUT DELETE] endpoints + authentication (No session, use jwt-token)

2. Pub / Sub

queues + workers combinations

  1. RabbitMq and Celery
  2. Amazon sqs and nodejs worker
  3. Google pubsub and Google Cloud functions

3. Push based communication

Queue pushes the message to


// Amazon lambda function

function send_email(emailid,message_body):

End Note:

Microservices definitely shine in a few usecases where the coupling between systems is low and the sheer scale is huge. However, it's not one-fit-all solution.

Like every bridge is different from other; so is every web app!

Please log in to add an answer.