1views

written 3.7 years ago by

yashbeer ★ 11k

Background

Broadly, web apps have two requirements:

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

Microservices

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:

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

Benefits of Microservices:

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

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

REST APIs
Pub/Sub (publisher + subscriber)
Push based communication

1. REST APIs

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

2. Pub / Sub

queues + workers combinations

RabbitMq and Celery
Amazon sqs and nodejs worker
Google pubsub and Google Cloud functions

3. Push based communication

Queue pushes the message to

↓

// Amazon lambda function

function send_email(emailid,message_body):
         email.send()

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!

ADD COMMENT EDIT