Microservice

Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. Microservices are an architectural style for web applications in which applications are structured as collections of loosely coupled services.

Microservices that make up an application can be placed within containers that possess the smallest libraries and executables needed by that service or application, making each container a self-contained package. Docker delivers an easy way to create, share, and test container images

Fault or Deviations in Microservice Communication -

When 1 Microservice communicate with other Microservice than due to some fault or delay in response by 1 service it could lead to certain problems .
it could be slow response, network failures, REST call failures, failures due to the high number of requests .Programmetically, fault tolerance can be handled by creating a RestController with a simple method that will demonstrate our functionality. Additionally, we will create a fallback method to tolerate the fault.

• Rate Limiting --- Rate Limiter limits the number of requests for a given period. Rate Limiting is done to protect the resources from spammers, minimize the overhead, meet a service level agreement etc. we can achieve this functionality with @RateLimiter  provided by Resilience4j.

Circuit Breaker

• Circuit Breaker -- When a microservice talks to another microservice which is faulty than it may lead to error or inaccurate response and this could also affect the other microservice response due to Cascading affect. So, under such situation instead of wanting Microservice to call the service methods , a fallback method is called . so, calling a fallback method instead of an actual service due to a fault is called breaking the circuit. annotation @CircuitBreaker is used for this.

BulkHead

• BulkHead --
Using Bulkhead, we can limit the number of concurrent requests within a particular period. Similar to rateLimiting but difference between Bulkhead and Rate Limiting is that Rate Limiter never talks about concurrent requests, but BulkheadLimiting annotation  @Bulkhead is use for this.

Time Limiting

• Time Limiting --- Time Limiting is the process of setting a time limit for a Microservice to respond . If 1 Microservice doesn’t respond to another within that time limit, then it will be considered that it has some fault . annotation @Timelimiter is use for this.

Architecture

The architecture of the app determines how it will interact with other apps, databases, integrated tools, middleware, and so on. Whether it will meet industry standards and business needs depends on the approach to architecture design. This is equally critical for mobile and web apps development services.

A Monolithic application is built as one single unit in which the user interface and data access code are combined into a single program on a single platform. Enterprise Monolithic applications are built in three parts: A database, consisting of many tables usually in a relational database management system. Client-side user interface consisting of HTML and/or JavaScript running in a browser. Problem with Monolithic Monolithic easy to develop, test & deployment . Problem is :
Even for a small change in the code, entire application needs to be re-built and re-deploy. The difficulties when deploying Monolith Architecture comes when scaling up. Every time you build, test and deploy, you have to change the whole monolith due to modules being extensively dependant on each other.
Best Usecase
Monolith Architecture is most effective on small projects with a well-defined scope, where you are unlikely to maintain or evolve the codebase on a recurring basis.

SOA

SOA is an architecture approach for defining, linking and integrating reusable business services that have clear boundaries and are self-contained with their own functionalities. These services communicate with each other to enable simple data passing or it could involve two or more services coordinating activity. The complexity of each service within SOA is usually very low and they communicate with each other over a set of APIs.

Pros
SOAs give you a great amount of flexibility when building complex architectures and one component will not bring down the rest of it if a deployment goes wrong.
Cons
SOAs give you a great amount of flexibility when building complex architectures and one component will not bring down the rest of it if a deployment goes wrong.
Usecase

Microservice

Microservices is an architectural style that organizes an application as a group of smaller services instead of a single bulky services . instead of sharing a single database schema with other services, each service has its own database schema. However, having a database schema per service is necessary if you want to take advantage from microservices, because it ensures loose coupling.
Microservices architecture breaks the application into smaller, completely independent components, enabling them to have greater agility and scalability. It is the logical evolution of SOA that supports modern business use-cases.

Microservices solve the problems of outdated Monolithic systems, this type of architecture consists of greater amounts of small services each running its own processes and are independently deployable therefore making it easier to understand, develop and test to enable Continuous Delivery and Continuous Improvement.
All the microservices have a shared database. Pros
Easy to develop, test, and deploy. Cons
Complexity
The biggest disadvantage of microservices lies in their complexity. Splitting an application into independent microservices entails more artifacts to manage.

Server-less Architecture

Serverless architecture is a cloud computing approach to building and running apps and services without the need for infrastructure management. In serverless apps, code execution is managed by a server, allowing developers to deploy code without worrying about server maintenance and provision. In fact, serverless doesn’t mean “no server.” The application is still running on servers, but a third-party cloud service like AWS takes full responsibility for these servers. A serverless architecture eliminates the need for extra resources, application scaling, server maintenance, and database and storage systems.

Pros
When using a serverless architecture, developers can focus on the product itself without worrying about server management or execution environments. This allows developers to focus on developing products with high reliability and scalability.

Monolithic Vs Microservice

A monolithic application is built as a single unified unit while a microservices architecture is a collection of smaller, independently deployable services. For a lightweight application, a monolithic system often suits better. For a complex, evolving application with clear domains, the microservices architecture will be the better choice.
Switching from monolithic to microservice is advisable as you can detect bugs or performance issues in a gradual fashion with microservices but is hard to come body incase of monolithic.
Monolithic architecture
pros -
Easy to deploy. We just need to copy the packaged application(jar, war, etc.) to a server.
Easy to test (Testing a single application is always easy).
Cons -
Even for a small change in the code, entire application needs to be re-built and re-deploy.
As the number of modules increase, then application size increases, downtime for re-deployment may also increase accordingly. As a result, the code becomes complex which is then hard to maintain.
Microservice(single-function service) architecture
instead of sharing a single database schema with other services, each service has its own database schema.
Cons -
Microservices Architecture includes a complexity,
Complexity arises when we need to implement the inter-process communication mechanism, including the additional implementation to handle partial failures.
Testing a microservices also becomes much more complex as compared to monolithic. For a similar test for a service you would need to launch that service and other services that it depends upon or at least configure stubs for those services.
Deployment of a Microservices Architecture based application is also much more complex.we need to configure, deploy, scale, and monitor each instance of microservices separately.
______
Once we complete writing Microservices Application, it must be published by the Register and Discovery Server (R&D Server) i.e. Netflix Eureka. In short, Eureka Server.
If any Microservice is throwing Exceptions repeatedly, then Stop Executing such Microservice for some duration and inform it to Admin Dashboard. In order to handle this, we use Circuit Breaker concept(via Netflix Hystrix). However, the new concept for Fault tolerance is Resilience4j as Hystrix is deprecated now.
______

Microservice Vs APIs

API stands for Application Programming Interface.
APIs r the point of contact for all the services through which all of these services communicate with each other. Simply put, APIs are the frameworks through which users interact with a web application. microservice often has an API. However, not all microservices need an API to function, and vice versa.
a microservice has to do more with the software’s architecture, and the API has to do with how to expose the microservice to a consumer. APIs are the entry point for microservices. They act as a gatekeeper, doing all the basic functionalities before passing the request to the respective application, allowing the end-user to interact with the application.
An API is a system that allows two or more applications to communicate.
APIs are necessary for the microservice architecture to function because it’s the communication tool between its services. Without an API, there would be a lot of disconnected microservices. If you want your microservice to be used, then you have to create an API.

Rest APIs Vs Streaming APIs

Rest API - r the standard that uses HTTP methods as input . Strong protocol and is more secure, built-in architecture layers.Format of data is based on HTTP. Restful API - It is less secure than rest. Format of data is based on HTTP, text, and JSON.
RESTful APIs are stateless. The API itself holds no client context on the server beyond that relevant to the immediate request and the information needed to authenticate the client. While it is technically true that this state can be stored elsewhere, like in a database, and thus would not “technically” be stored in the API itself, that’s not really “state” as much as it is “stored context”.
Sreaming APIs - Streaming APIs are almost an exact opposite of the REST ethos. In its most basic state, Streaming APIs invert the conversational nature of REST.REST APIs are stateless, Streaming APIs are by their very nature stateful. Without storing state in some form, the Streaming API cannot properly contextualize the data relationship with the requesting client.
If understand the two with an analogy If REST APIs are a conversation, Streaming APIs are more akin to watching a movie in a movie theater – if REST is two people talking, a Streaming API is a person buying a movie ticket, sitting in a theater, and passively receiving the film.
examples of Streaming APIs include the Twitter API,real-time Salesforce API

Rest APIs Vs Restful APIs

APIs (Application Programming Interface) act as an interface between two applications to interact and provide the relevant data. It uses a set of protocols using which the operation is done. Salesforce was the first organization to officially launch API, followed by eBay and Amazon. Also, 60% of transactions made on eBay use their APIs.
REST (Representational State Transfer), is an API that follows a set of rules through which applications and servers communicate. It was specifically designed for working with components like files, objects, and media components. REST uses HTTP requests like GET, PUT, POST, and DELETE to manage CRUD (Create, Read, Update, and Delete) operations.
REST Demerits -
RESTful API is a standardized implementation of the REST architecture, which makes it easier for developers to build and maintain web services.RESTful API supports caching, which can improve performance by reducing the number of requests sent to the server. RESTful API can be used with a variety of data formats, including XML and JSON.

Webservice Vs APIs

Jar files which we use in our project are also APIs but not web APIs. The key difference is web service supports only HTTP while API supports HTTP/HTTPS protocol. A type of API is a web service.
An API is a set of definition & protocols to allow communication between 2 applications.apis can be available in online or offline mode but web services need internet connection to make communication possible. Web service only support http protocol . API allows both http/https protocol and supports xml & Json both while web service supports only xml .Many APIs r open source and publicly available by documentation. Web services r not open source. A web service is an API wrapped in http .
All web service r API but not all API r web service.
_______
Container & microservice r like milk & cookies.You can operate microservices without containers

API Vs WebHooks Vs Websockets


Webhooks Vs API
webhook is a subset of an API. If you're looking to send a notification or update information as soon as a certain criterion is met, avoid the hassle of an API—just implement a simple webhook. If you're dealing with fluctuating data or want to modify data rather than merely push a notification, you'll probably need to implement an API.
the data you want to access is constantly being updated. If it is, an API will likely make more sense than a webhook. If it isn't, consider implementing a webhook instead.
Webhooks and WebSockets are two technologies that handle communications over the web.
Webhooks Functioning
To better understand the working mechanism of Webhooks, consider a web application that uses Stripe’s API to receive payments. Whenever a customer makes a payment, Stripe receives the money, but your app has no idea.Stripe requires you to provide a Webhook endpoint URL to send the customer’s payment data to your server when a new payment event is triggered. Your server then receives the data, performs operations on it, and saves persistent data to the database.

websocket
It establishes a two-way, persistent, bidirectional communication channel. It does so over a single connection made between two TCP ports from a client (browser) to a server. The most popular application of WebSockets is in chat applications like WhatsApp.

Webhooks are HTTP based (i.e make use of the HTTP protocol), WebSocket is an entire protocol on its own based on TCP just like HTTP. WebSockets can be very beneficial when working on low-latency server-client data streaming applications.You can achieve low latency with a WebSocket connection because it stays open between transactions, unlike default HTTP. This allows data to flow seamlessly between both parties.


So when should you choose Webhooks over WebSockets?

When consuming an API you don’t own. Consider the Stripe example from the earlier Webhook illustration. Stripe is a payment service provider and your application can only build on top of their API. You have no control over Stripe, so you can’t create a WebSocket server at their end. In cases like this, you should use Webhooks.
If your app is a server that needs to communicate with another server, it’s best to use Webhooks.
It is also noteworthy that Webhooks are the ideal way to go for server operations that run as serverless functions. Examples include AWS Lambda and Google cloud functions.

When Should You Use WebSockets?
You should use WebSockets when your application continuously exchanges data between the client and server. For example, in a live location-sharing application, a user’s location is continuously updated on both the server and client as they move.
Other cases where you should use WebSockets include live video/audio streaming apps, live notification systems, and real-time multiplayer games. They’re also useful in collaborative editing applications like Google Docs, Notion, etc.

API Gateway

API Gateway acts as a "front door" for applications to access data, business logic, or functionality from your backend services.An API gateway is a component that sits between your backend services and your API clients.routing requests from clients to the appropriate backend service and then returning the service's response back to the client. When we as a user request for a service in the application than our request for the needed functionality is sent to the respective microservice by the API gateway and than the fetched response is received to us as the output.
API Gateway Vs Service RegistryThe API gateway operates at the application level and stands between the user and internal applications logic, while the service registry mesh stands between the internal microservices.
Instead of calling services directly, clients call the API gateway(Edge Microservice ),
which forwards the call to the appropriate services on the back end. It works as a middleware between eureka server & microservice.
Pros -
External clients don’t need to pass through the authentication of each & every microservice. External client only needs to pass authentication of only one microservice at the beginning which is the API Gateway. We don’t need to expose the endpoints of microservices to the external application/client.
Cons -
Since every request goes through API Gateway after a security check, it may slow down the performance.
2. Suppose we implement only one API gateway for the multiple microservices & if API Gateway fails, the request will not be processed further. Hence, we should implement multiple Gateways and manage the traffic via load balancer.

Eureka Server

Eureka (client side service discovery) server ->
To allow microservices to communicate with each other there is requirement of a common medium where details of every microservice is stored. A common medium is nothing but Eureka Server. All microservices will register with Eureka Server as a discovery client.  Eureka most commonly used for service registry & discovery in the context of Microservices.Hence , we need to create a Eureka Server to register and discover the microservices.
Service Registry is the process of registering a microservice with Eureka Server. In a nutshell, it acts as a kind of database which stores the details of all microservices involved in the entire application.to enable the service registry, we apply annotation @EnableEurekaServer on the top of the Application’s main class. 
Service Discovery is the process of discovering other microservices in the network to make intra-communication happen. With @EnableEurekaServer, other microservices can register here and communicate with each other via service discovery.
Add this in application.properties
server.port=8761 eureka.client.register-with-eureka=false eureka.client.fetch-registry=false

Service Registry

A service registry is a database used to keep track of the available instances of each microservice in an application. The service registry needs to be updated each time a new service comes online and whenever a service is taken offline or becomes unavailable.In general sense , A service registry is a database for the storage of data structures for application-level communication. It serves as a central location where app developers can register and find the schemas used for particular apps.

Server side service discovery

Service Discovery -Microservices service discovery is a way for applications and microservices to locate each other on a network.The discovery server monitors its client's uptime using “heartbeat” model. In case a service goes down, the load balancer will notice it and automatically manage the load coming to it.
Server-side service discovery allows clients applications to find services through a router or a load balancer.eg... Amazon Web Services (AWS) Elastic Load Balancer (ELB).

CLient side service discovery

Client-side service discovery allows clients applications to find services by looking through or querying a service registry, in which service instances and endpoints are all within the service registry.
Server side service discovery is good to use than client side - the client code is simpler in server side since it does not have to deal with discovery. Instead, a client simply makes a request to the router.

Use of Jars in microservices

JAR stands for Java Archive.They are packaged with the ZIP file format, so you can use them for tasks such as lossless data compression, archiving, decompression, and archive unpacking. It contains the combination of multiple java files into a single JAR archive file.It is designed to facilitate the packaging of java applets or applications into a single archive. JARs are a pretty JVM-specific packaging system.
When we develop a heavy microservice based application than it may require a lot of libraries(or we call them jars) to incorporate certain properties in your application to be used pre-hand without any need to develop logic for those functionality.We use build tool like- maven,gradle to include all the libraries that are supportable to develop some new functionalities into our application.

Firebase Vs Rest API

Firebase synced data across all clients in real time & remains available when our app goes offline .It has a cloud-hosted NoSQL database that lets you sync between your users in real-time.
The Firebase db is a cloud hosted dB in which data is stored in json. It is good when the amount of data is small because it is difficult to fetch condition based data from large db with it.
From huge amount of data we can create our own rest apis that can allow to & fro of datavery easily.
Why not to use firebase as a backend option for storage ->
It stores data in the form of json not sql. So, if I want to fetch some data based on my need like give me only names of the employees with given experience than firebase can't fetch the exact data we need. Such data r easier to fetch from sql db but not from json data hence we have to make some compromises while using firebase as it is not going to give the same result we r seeking. it is difficult to fetch condition based data from large database if you are using Firebase. So, we have to change our logic to query for the data we want .and In case you need to change the logic to query data, you need to update your app. While Doing upgrades is very easy if REST API is used
It's becomes expensive when our app grows when more number of people visits our app but rest api will save time and money in the long run if such situations r to be met with it.
____________
Should I use REST API or just firebase to make an app like Uber or both? We use Firebase database for small database holding less amount of data because, it is difficult to fetch condition based data from large database if you are using Firebase . Whereas, when we have a large/complex database and we need to send/receive data to/from there, then we create our own REST APIs and that is way more flexible than using Firebase.
Cons with rest api
We need to host our server somewhere (heroku/AWS/Azure/etc.) and it will cost money also . but no such adjustment needed ro make incase of Firebase as it has it's own server .

CQRS

cqrs design pattern in microservice architecture -> cqrs design pattern is used when quering in microservices.
We can use CQRS design pattern in order to avoid complex queries to get rid of inefficient joins. CQRS stands for Command and Query Responsibility Segregation. Basically this pattern separates read and update operations for a database.
Need for CQRS ->
Normally, in monolithic applications, most of time we have 1 database and this database should respond both query and update operations. That means a database is both working for complex join queries, and also perform CRUD operations. But if the application goes more complex this query and crud operations will be also is going to be un-manageable.
cqrs allows separate reading database and the writing database with 2 database. By this way we can even use different database for reading and writing database types like using no-sql for reading and using relational database for crud operations.
So we can say that CQRS separates reads and writes into different databases, Commands performs update data, Queries performs read data. Now since cqrs uses 2 d/f db than to maintain syncing b/w these 2 db we can use Kafka for syncing these 2 database with pub/sub Kafka topic exchanges.
Real life usecase -> Instagram Database Architecture
Instagram basically uses two database systems, one is relational database PostgreSQL and the other is no-sql database — Cassandra.Cassandra database for user stories that is read-incentive data. And using relational PostgreSQL database for User Information bio update.

Webservice Vs microservices

Both r based on http protocol. Microservices and web services are two different approaches to building web applications. Microservices are a modular, component-based approach to building applications, while web services are typically built as monolithic applications.
Microservices are typically deployed as independent, self-contained services, while web services are deployed as a single unit. Microservices are typically deployed in a cloud-based environment, while web services are usually deployed in a traditional on-premises environment. Microservices are highly scalable, while web services are designed for a more limited scale.
Microservices are designed to be stateless, while web services are typically designed to be stateful. Few central types of web services: XML-RPC, UDDI, SOAP, and REST: SOAP & REST r software architecture to create API .

microservice Design pattern

Top 6 microservice patterns -
Database Per Service Pattern - as its name implies, each microservice has its own dedicated database. Not an easy pattern to implement as there’s lots of potential drawbacks and overhead in architecture development. Loose coupling and scaling are pluses.
Single Database Pattern - microservices share one DB - a bit more forgiving approach than 1. The downside is coordination of efforts and cross-dependencies, which goes against the very philosophy of microservices.
Saga Pipeline Pattern - a sequential pipeline of transactions that takes place with microservice “commit” events.
API Composition Pattern - used for implementing complex queries in a microservices architecture.
Command Query Responsibility Segregation Pattern - addresses the challenge of querying multiple microservices by defining a special database view designed to support such query.
Event sourcing Pattern addresses the problem of maintaining data consistency across microservices (an alternative to this would be another pattern called “Transaction Log Trail”)