Scribd
Upload
94 views

Interprocess Communication in Microservice

The document discusses various patterns and considerations for designing microservices architectures, including using a service registry for dynamic IP addresses, circuit breakers for handling unavailable services, Kafka for message queuing and streaming, and managing transactions across services using sagas. It also covers topics like domain-driven design, event sourcing, querying with CQRS, external APIs, testing, and production readiness.

Uploaded by

Harish Kumar
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
94 views

Interprocess Communication in Microservice

The document discusses various patterns and considerations for designing microservices architectures, including using a service registry for dynamic IP addresses, circuit breakers for handling unavailable services, Kafka for message queuing and streaming, and managing transactions across services using sagas. It also covers topics like domain-driven design, event sourcing, querying with CQRS, external APIs, testing, and production readiness.

Uploaded by

Harish Kumar
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

INTERPROCESS COMMUNICATION IN MICROSERVICE

 Each Service needs to have its own database (schema per service)
 Circuit Breaker pattern for timeouts (if one service is down, other dependent service needs to
handle timeout or else entire application will be down)
 Service registry used to get dynamic IP address of instances (Kubernetes)
 Send cached version from unavailable services
 Transactional messaging is handled by tables of same database

QUEUE / DATA STREAMING

 Use Kafka for queue and streaming


 Data should be ordered while passing to services -> Shard channels available in apache Kafka
 Handling duplicate messages using tracking and discarding (track message id in table and check
for duplicate while processing message)

MANAGING TRANSACTIONS WITH SAGAS


The saga design pattern is a way to manage data consistency across microservices in distributed
transaction scenarios. A saga is a sequence of transactions that updates each service and
publishes a message or event to trigger the next transaction step.

DESIGNING BUSINESS LOGIC IN A MICROSERVICE ARCHITECTURE


 Domain driven design pattern for complex business logic

DEVELOPING BUSINESS LOGIC WITH EVENT SOURCING


 Load each aggregate event to a table

IMPLEMENTING QUERIES IN A MICROSERVICE ARCHITECTURE


 Querying using API composition pattern (gets data from different database and combine into
single service)
 CQRS consist of separate database for read operations (Views instead of tables)
 Apache spark can be used for CQRS, rather than kafka
EXTERNAL API PATTERNS
 Mobile applications have higher latency than web applications (since we call many server api’s
using mobile app)
 Reverse proxy features using NGINX
 Backends for frontends (Separate api modules for web, mobile, third party)
 Async IO model (Netflix Zuul) or API using graphQL

TESTING MICROSERVICES
 Consumer driven Contract testing
 Integrated testing
 Component testing
 End to end testing

PRODUCTION READY SERVICES


 OAuth 2.0 uses access token and refresh token for authentication
 Read external appsettings file during startup [set credentials in dev,qa,prod]

ARCHITECTURE PATTERNS (https://docs.microsoft.com/en-us/azure/architecture/patterns/)

Bulkhead -> run services with isolated memory and ram


CQRS -> different models for read and write from database

You might also like