I&#39;m learning about microservices and I&#39;m gonna build a project with a microservices architecture.

The thing is, one of my team mates want to use one database for all services, sharing all tables so &quot;data doesn&#39;t get repeated&quot;, each service would be built with different frameworks and languages like django and rails which use very different ORM standards.

What would be the correct approach? Since I think working with one database would involve a lot of &quot;hacking&quot; the ORMs in order to make them work correctly.

Microservices with shared database? using multiple ORM&#39;s?

Nowadays in microservice world, i’m seeing alot of design in my workplace that uses kafka messaging when you can achieve similar results using rest api calls between microservices. Technically you can stop using rest api calls altogether and instead use kafka messaging. I really want to know the best practice, pros and cons, when to use api calls between microsevices, when to use kafka messaging. 


Lets put a real life example:

I have an inventory service and a vendor service. Everyday vendor service calls the vendor API to get new items and these need to be moved into inventory service. The number of items can be up to 10,000 objects.

For this use case, is it better to :

1. After getting new data from vendor API, call REST API of inventory service to store the new items.

2. After getting new data from vendor API, send them as message to a kafka topic, to be consumed by inventory service 

Which way would you choose and what is the consideration

Kafka Msg VS REST Calls

I&#39;m trying to design a green-field project that will have several services (serving data) and web-applications (serving HTML). I&#39;ve read about microservices and they look like good fit.

The problem I still have is how to implement SSO. I want the user to authenticate once and have access to all the different services and applications.

I can think of several approaches:

1. Add Identity service and application. Any service that has protected resources will talk to the Identity service to make sure the credentials it has are valid. If they are not it will redirect the user for authentication.

2. Use a web-standard such as OpenID and have each service handle it own identities. This means the user will have to authorize individually each service/application but after that it will be SSO.

I&#39;ll be happy to hear other ideas. If a specific PaaS (such as Heroku) has a proprietary solution that would also be acceptable.

Single Sign-On in Microservice Architecture

I am trying to understand in which scenario I should pick a service registry over a load balancer.

From my understanding both solutions are covering the same functionality.

For instance if we consider **consul.io** as a feature list we have:

 - Service Discovery
 - Health Checking
 - Key/Value Store
 - Multi Datacenter

Where a load balancer like **Amazon ELB** for instance has:

 - configurable to accept traffic only from your load balancer
 - accept traffic using the following protocols: HTTP, HTTPS (secure HTTP), TCP, and SSL (secure TCP)
 - distribute requests to EC2 instances in multiple Availability Zones
 - The number of connections scales with the number of concurrent requests that the load balancer receives
 - configure the health checks that Elastic Load Balancing uses to monitor the health of the EC2 instances registered with the load balancer so that it can send requests only to the healthy instances
 - You can use end-to-end traffic encryption on those networks that use secure (HTTPS/SSL) connections
 - [EC2-VPC] You can create an Internet-facing load balancer, which takes requests from clients over the Internet and routes them to your EC2 instances, or an internal-facing load balancer, which takes requests from clients in your VPC and routes them to EC2 instances in your private subnets. Load balancers in EC2-Classic are always Internet-facing.
 - [EC2-Classic] Load balancers for EC2-Classic support both IPv4 and IPv6 addresses. Load balancers for a VPC do not support IPv6 addresses.
 - You can monitor your load balancer using CloudWatch metrics, access logs, and AWS CloudTrail.
 - You can associate your Internet-facing load balancer with your domain name. 
 - etc.

So in this scenario I am failing to understand why I would pick something like `consul.io` or `netflix eureka` over `Amazon ELB` for service discovery.


I have a hunch that this might be due to implementing **client side service discovery** vs **server side service discovery**, but I am not quite sure.

Service discovery vs load balancing

I see more and more software organizations using gRPC in their service-oriented architectures, but people are also still using REST. In what use cases does it make sense to use gRPC, and when does it make sense to use REST for inter-service communication?

Interestingly, I&#39;ve come across open source projects that use both REST and gRPC. For instance, Kubernetes and Docker Swarm all employ gRPC to some extent for cluster coordination, but also expose REST APIs for interfacing with master/leader nodes. Why not use gRPC up and down?

REST vs gRPC: when should I choose one over the other?

I have a service-based application that uses Amazon SQS with multiple queues and multiple consumers. I am doing this so that I can implement an event-based architecture and decouple all the services, where the different services react to changes in state of other systems. For example:

- **Registration Service**: 
  - Emits event &#39;registration-new&#39; when a new user registers.
- **User Service**: 
  - Emits event &#39;user-updated&#39; when user is updated.
- **Search Service**: 
  - Reads from queue &#39;registration-new&#39; and indexes user in search.
  - Reads from queue &#39;user-updated&#39; and updates user in search.
- **Metrics Service**:
  - Reads from &#39;registration-new&#39; queue and sends to Mixpanel.
  - Reads from queue &#39;user-updated&#39; and sends to Mixpanel.

I&#39;m having a number of issues:

  - A message can be received multiple times when doing polling. I can design a lot of the systems to be idempotent, but for some services (such as the metrics service) that would be much more difficult.
  - A message needs to be manually deleted from the queue in SQS. I have thought of implementing a &quot;message-handling-service&quot; that handles the deletion of messages when all the services have received them (each service would emit a &#39;message-acknowledged&#39; event after handling a message).

I guess my question is this: what patterns should I use to ensure that I can have multiple consumers for a single queue in SQS, while ensuring that the messages also get delivered and deleted reliably. Thank you for your help.

Using Amazon SQS with multiple consumers

I&#39;m developing my insight about distributed systems, and how to maintain data consistency across such systems, where business transactions covers multiple services, bounded contexts and network boundaries.

Here are two approaches which I know are used to implement distributed transactions:

- 2-phase commit (2PC)
- Sagas

2PC is a protocol for applications to *transparently* utilize global ACID transactions by the support of the platform. Being embedded in the platform, it is transparent to the business logic and the application code as far as I know.

Sagas, on the other hand, are series of local transactions, where each local transaction mutates and persist the entities along with some flag indicating the phase of the global transaction and commits the change. In the other words, state of the transaction is part of the domain model. Rollback is the matter of committing a series of &quot;inverted&quot; transactions. Events emitted by the services triggers these local transactions in either case.

Now, when and why would one use sagas over 2PC and vice versa? What are the use cases and pros/cons of both? Especially, the brittleness of sagas makes me nervous, as the inverted distributed transaction could fail as well.

2PC vs Sagas (distributed transactions)

As far as I can tell, &quot;service discovery&quot; means a way for a client to find out about a server (or cluster of servers) that it wants to connect to.

I&#39;ve built web applications that communicate with other back-end processes using protocols like HTTP and AMQP. In those, each client has a config file that contains a host name or whatever information it needs to connect to the server, which gets set at deployment time using a configuration tool like Ansible. That&#39;s simple and seems to work pretty well.

Is service discovery an alternative to just putting server information in a client&#39;s config file? If so, why is it better? If not, what problem does it solve?


What is service discovery, and why do you need it?

I&#39;m trying to understand where GraphQL is most suitable to use within a microservice architecture. 

There is some debate about having only 1 GraphQL schema that works as API Gateway proxying the request to the targeted microservices and coercing their response. Microservices still would use REST / Thrift protocol for communication though.

Another approach is instead to have multiple GraphQL schemas one per microservice. Having a smaller API Gateway server that route the request to the targeted microservice with all the information of the request + the GraphQL query.

**1st Approach**

Having 1 GraphQL Schema as an API Gateway will have a downside where every time you change your microservice contract input/output, we have to change the GraphQL Schema accordingly on the API Gateway Side.

**2nd Approach**

If using Multiple GraphQL Schema per microservices, make sense in a way because GraphQL enforces a schema definition, and the consumer will need to respect input/output given from the microservice.

**Questions**

- Where do you find GraphQL the right fit for designing microservice architecture? 

- How would you design an API Gateway with a possible GraphQL implementation?

When and How to use GraphQL with microservice architecture

What is the standard pattern of orchestrating microservices?

If a microservice only knows about its own domain, but there is a flow of data that requires that multiple services interact in some manner, what&#39;s the way to go about it?

Let&#39;s say we have something like this:

* Invoicing
* Shipment

And for the sake of the argument, let&#39;s say that once an order has been shipped, the invoice should be created. 

Somewhere, someone presses a button in a `GUI`, &quot;I&#39;m done, let&#39;s do this!&quot;
In a classic monolith service architecture, I&#39;d say that there is either an `ESB` handling this, or the Shipment service has knowledge of the invoice service and just calls that.

But what is the way people deal with this in this brave new world of microservices?

I do get that this could be considered highly opinion-based. but there is a concrete side to it, as microservices are not supposed to do the above.
So there has to be a &quot;what should it by definition do instead&quot;, which is not opinion-based.

Shoot.

Orchestrating microservices

Let&#39;s say we have a User, Wallet REST microservices and an API gateway that glues things together. When Bob registers on our website, our API gateway needs to create a user through the User microservice and a wallet through the Wallet microservice. 

Now here are a few scenarios where things could go wrong:

- User Bob creation fails: that&#39;s OK, we just return an error message to the Bob. We&#39;re using SQL transactions so no one ever saw Bob in the system. Everything&#39;s good :)

- User Bob is created but before our Wallet can be created, our API gateway hard crashes. We now have a User with no wallet (inconsistent data).

- User Bob is created and as we are creating the Wallet, the HTTP connection drops. The wallet creation might have succeeded or it might have not.

What solutions are available to prevent this kind of data inconsistency from happening? Are there patterns that allow transactions to span multiple REST requests? I&#39;ve read the Wikipedia page on [Two-phase commit](http://en.wikipedia.org/wiki/Two-phase_commit_protocol) which seems to touch on this issue but I&#39;m not sure how to apply it in practice. This [Atomic Distributed Transactions: a RESTful design](http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf) paper also seems interesting although I haven&#39;t read it yet.

Alternatively, I know REST might just not be suited for this use case. Would perhaps the correct way to handle this situation to drop REST entirely and use a different communication protocol like a message queue system? Or should I enforce consistency in my application code (for example, by having a background job that detects inconsistencies and fixes them or by having a &quot;state&quot; attribute on my User model with &quot;creating&quot;, &quot;created&quot; values, etc.)?

Transactions across REST microservices?

I&#39;m having a hard time choosing a decent/secure authentication strategy for a microservice architecture. The only SO post I found on the topic is this one: https://stackoverflow.com/questions/25595492/single-sign-on-in-micro-service-architecture

My idea here is to have in each service (eg. authentication, messaging, notification, profile etc.) a unique reference to each user (quite logically then his `user_id`) and the possibility to get the current user&#39;s `id` if logged in.


From my researches, I see there are two possible strategies:

### 1. Shared architecture
![Shared architecture][1]

In this strategy, the authentication app is one service among other. But each service must be able to make the conversion `session_id` =&gt; `user_id` so it must be dead simple. That&#39;s why I thought of Redis, that would store the key:value `session_id:user_id`.

### 2. Firewall architecture
![Firewall architecture][2]

In this strategy, session storage doesn&#39;t really matter, as it is only handled by the authenticating app. Then the `user_id` can be forwarded to other services. I thought of Rails + Devise (+ Redis or mem-cached, or cookie storage, etc.) but there are tons of possibilities. The only thing that matter is that Service X will never need to authenticate the user.

---

How do those two solutions compare in terms of:

- security
- robustness
- scalability
- ease of use

Or maybe you would suggest another solution I haven&#39;t mentioned in here?

I like the solution #1 better but haven&#39;t found much default implementation that would secure me in the fact that I&#39;m going in the right direction.


  [1]: http://i.stack.imgur.com/po7Qr.png
  [2]: http://i.stack.imgur.com/NHGjh.png

Microservice Authentication strategy

In order to deal with the microservice architecture, it&#39;s often used alongside a Reverse Proxy (such as nginx or apache httpd) and for cross cutting concerns implementation  [API gateway pattern is used][2]. Sometimes Reverse proxy does the work of API gateway.

It will be good to see clear differences between these two approaches.
It looks like the potential benefit of API gateway usage is invoking multiple microservices and aggregating the results. All other [responsibilities][1] of API gateway can be implemented using Reverse Proxy. Such as:

 - Authentication (It can be done using nginx LUA scripts);
 - Transport security. It itself Reverse Proxy task;
 - Load balancing
 - ...

So based on this there are several questions:

 1. Does it make sense to use API gateway and Reverse proxy simultaneously (as example request -&gt; API gateway -&gt; reverse proxy(nginx) -&gt; concrete microservice)? In what cases ?
 2. What are the other differences that can be implemented using API gateway and can&#39;t be implemented by Reverse proxy and vice versa?

  [1]: https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/
  [2]: https://www.nginx.com/blog/building-microservices-using-an-api-gateway/

API gateway vs. reverse proxy

For people that are splitting up monolithic applications into microservices how are you handling the connundrum of breaking apart the database.  Typical applications that I&#39;ve worked on do a lot of database integration for performance and simplicity reasons.

If you have two tables that are logically distinct (bounded contexts if you will) but you often do aggregate processing on a large volumes of that data then in the monolith you&#39;re more than likely to eschew object orientation and are instead using your database&#39;s standard JOIN feature to process the data on the database prior to return the aggregated view back to your app tier.

How do you justify splitting up such data into microservices where presumably you will be required to &#39;join&#39; the data through an API rather than at the database.

I&#39;ve read Sam Newman&#39;s Microservices book and in the chapter on splitting the Monolith he gives an example of &quot;Breaking Foreign Key Relationships&quot; where he acknowledges that doing a join across an API is going to be slower - but he goes on to say if your application is fast enough anyway, does it matter that it is slower than before?

This seems a bit glib?  What are people&#39;s experiences?  What techniques did you use to make the API joins perform acceptably?

Microservices and database joins

Lately I&#39;ve been doing some experiments with docker compose in order to deploy multiple collaborating microservices. I can see the many benefits that microservices provide, and now that there is a good toolset for managing them, I think that it&#39;s not extremely hard to jump into the microservices wagon.

But, I have been experimenting with Elixir too, and I am quite fond of the benefits that provides by itself. Given that it encourages packing your code into multiple decoupled applications, and supports hot code upgrades, how would you mix docker with elixir (or erlang, for that matter)?

For example, if I want to use docker because it provides dev-prod parity, how does elixir fit in that? Given that docker containers are immutable, I lose the ability to do hot-code upgrades, right? What about blue/green deployments or canary releases?

I mean, I could just write microservices with Elixir and use them as if they were written in any other language, polyglotism is one of the benefits of microservices anyway, but then I&#39;m not getting the full benefits of using the OTP platform, I guess that pure collaborative erlang applications are way more optimal that using intermediate queues to communicate between microservices written in different (or not) languages.

Where does Elixir/erlang fit into the microservices approach?

Microservices architecture suggest that each service should handle it&#39;s own data. Hence any service (Service A) dependent on data owned by other service (service B) should access such data not by making direct DB calls but through the api provided by the second service (service B).

**So what does microservices best practices suggest on checking foreign key constrains.** 

Example: I am developing a delivery feature (microservice 1) for products and certain products are deliverable to only certain locations as mentioned in the products table accessible to only products micro service (mircoservice 2).

How do I make sure that microservice 1 (i.e delivery feature) does not take an order to a unserviced location. I have this question because delivery feature can not directly access products database, so there is no constraints applicable at DB level when a delivery order is place in to delivery data base (no check is possible to see if a foreign key match exists in products database or table).

Microservices: how to handle foreign key relationships

What are advantages and disadvantages of microservices and monolithic architecture?

When to chose microservice architecture or monolithic architecture?

Microservices vs Monolithic Architecture

I just read an article on [Microservices and PaaS Architecture](http://java.dzone.com/articles/microservices-and-paas-part-2). In that article, about a third of the way down, the author states (under **Denormalize like Crazy**):

&gt; Refactor database schemas, and de-normalize everything, to allow complete separation and partitioning of data. That is, do not use underlying tables that serve multiple microservices. There should be no sharing of underlying tables that span multiple microservices, and no sharing of data. Instead, if several services need access to the same data, it should be shared via a service API (such as a published REST or a message service interface).

While this *sounds* great in theory, in practicality it has some serious hurdles to overcome. The biggest of which is that, often, databases are tightly coupled and every table has *some* foreign key relationship with at least one other table. Because of this it could be impossible to partition a database into *n* sub-databases controlled by *n* microservices.

So I ask: **Given a database that consists entirely of related tables, how does one denormalize this into smaller fragments (groups of tables) so that the fragments can be controlled by separate microservices?**

For instance, given the following (rather small, but exemplar) database:

    [users] table
    =============
    user_id
    user_first_name
    user_last_name
    user_email

    [products] table
    ================
    product_id
    product_name
    product_description
    product_unit_price

    [orders] table
    ==============
    order_id
    order_datetime
    user_id

    [products_x_orders] table (for line items in the order)
    =======================================================
    products_x_orders_id
    product_id
    order_id
    quantity_ordered

Don&#39;t spend too much time critiquing my design, I did this on the fly. The point is that, to me, it makes logical sense to split this database into 3 microservices:

 1. `UserService` - for CRUDding users in the system; should ultimately manage the `[users]` table; and
 2. `ProductService` - for CRUDding products in the system; should ultimately manage the `[products]` table; and
 3. `OrderService` - for CRUDding orders in the system; should ultimately manage the `[orders]` and `[products_x_orders]` tables

However all of these tables have foreign key relationships with each other. If we denormalize them and treat them as monoliths, they lose all their semantic meaning:

    [users] table
    =============
    user_id
    user_first_name
    user_last_name
    user_email

    [products] table
    ================
    product_id
    product_name
    product_description
    product_unit_price

    [orders] table
    ==============
    order_id
    order_datetime

    [products_x_orders] table (for line items in the order)
    =======================================================
    products_x_orders_id
    quantity_ordered

**Now there&#39;s no way to know who ordered what, in which quantity, or when.**

So is this article typical academic hullabaloo, or is there a real world practicality to this denormalization approach, and if so, what does it look like (bonus points for using my example in the answer)?

How does data denormalization work with the Microservice Pattern?

We want to build a Javascript/HTML gui for our gRPC-microservices. Since gRPC is not supported on the browser side, we thought of using web-sockets to connect to a node.js server, which calls the target service via grpc. 
We struggle to find an elegant solution to do this. Especially, since we use gRPC streams to push events between our micro-services.
It seems that we need a second RPC system, just to communicate between the front end and the node.js server. This seems to be a lot of overhead and additional code that must be maintained.

Does anyone have experience doing something like this or has an idea how this could be solved?

How to bring a gRPC defined API to the web browser

**Background:**

I am building an application and the proposed architecture is Event/Message Driven on a microservice architecture. 

The monolithic way of doing thing is that I&#39;ve a `User/HTTP request` and that actions some commands that have a direct `synchronous response`. Thus, to respond to the same User/HTTP request is &#39;hassle free&#39;.


[![enter image description here][1]][1]

**The problem:**

The user sends an `HTTP request` to the **UI Service** (there are multiple UI Services) that fires some events to a queue (Kafka/RabbitMQ/any). a N of services picks up that Event/Message do some magic along the way and **then at some point that same UI Service should pick that up a response and give that back to the user that originated HTTP request.** Request processing is `ASYNC` but the `User/HTTP REQUEST-&gt;RESPONSE` is `SYNC` as per your typical HTTP interaction.

**Question:**
How do I send a response to the same UI Service that originated the action (The service thats interacting with the user over HTTP) in this Agnostic/Event driven world?

**My research so far** 
I&#39;ve been looking around and it seems that some people are solving that problem using WebSockets.

But the layer of complexity is that there needs to be some table that maps `(RequestId-&gt;Websocket(Client-Server))` which is used to ‘discover’ which node in the gateway has the websocket connection for some particular response. But even if I understand the problem and complexity I&#39;m stuck that I can&#39;t find any articles that would give me info on how to solve this problem at the implementation layer. **AND** this still is not a viable option because of 3rd party integrations such as payments providers(WorldPay) that expect `REQUEST-&gt;RESPONSE` - specially on the 3DS validation.


So I am somehow reluctant to think that WebSockets is an option. But even if WebSockets are ok for Webfacing apps, for API that connects to external systems is not a great architecture.


** ** ** **Update:** ** ** ** 

Even if long polling is an possible solution for a WebService API with a `202 Accepted` a `Location header` and a `retry-after header` it wouldn&#39;t be performant for a high concurrency &amp; high ability website. 
Imagine a huge number of people trying to get the transaction status update on EVERY request they make and you have to invalidate CDN cache (go and play with that problem now! ha).

But most important and relatable to my case I&#39;ve 3rd party APIs such as payment systems where the 3DS systems have automatic redirects that are handled by the payment provider system and they expect a typical `REQUEST/RESPONSE flow`, thus this model would not work for me nor the sockets model would work. 

Because of this use-case the `HTTP REQUEST/RESPONSE` should be handled in the typical fashion where i have a dumb client that expect that the complexity of the precessing is handled in back-end.

**So i am looking for a solution where externally I have a typical `Request-&gt;Response`(SYNC) and the complexity of the status(ASYNCrony of the system) is handled internally** 

 
An example of the long polling, but this model wouldn&#39;t work for 3rd party API such as payments provider on `3DS Redirects` that are not within my control.

     POST /user
        Payload {userdata}
        RETURNs: 
            HTTP/1.1 202 Accepted
            Content-Type: application/json; charset=utf-8
            Date: Mon, 27 Nov 2018 17:25:55 GMT
            Location: https://mydomain/user/transaction/status/:transaction_id
            Retry-After: 10
    
    GET 
       https://mydomain/user/transaction/status/:transaction_id



[![enter image description here][2]][2]




  [1]: https://i.stack.imgur.com/rP5nf.png
  [2]: https://i.stack.imgur.com/rznNC.png


How to handle HTTP requests in a Microservice / Event Driven Architecture?

I am doing some research on how to split a huge single-page-monolith into a micro-frontend architecture.

# The idea:

 - the page consists of several components which would be running autonomously
 - each component is managed by one dev-team
 - each team can change, update and deploy their components without breaking components of other teams
 - each team chooses its own toolstack

# The reason

To efficiently develop large applications you need to have many people working on it. However the number of developers per app/team does not scale well. Parallel development of multiple independent apps by independent teams however can be scaled arbitrarily

With this in mind it is imperative that teams can choose their own toolstack and especially perform independent version-upgrades of third party-libraries (like angular, react, jquery). If this was not the case a framework-update would need to be compatible with every single component before you could deploy it to production.

# Does this work with Angular?

While independent version-upgrades are necessary, it would be reasonable to restrict the teams to a few supported frameworks (Angular, React, Vue, Polymer...) and for now I try to build a demo purely consisting of Angular-Apps.

However even though Angular 5 is supposedly a platform-framework which supports huge multi-module apps, it seems to be almost impossible to have several independent angular-apps running in the same browser window.

I managed to bootstrap several Angular-Apps (different versions, each hosted on its own server) on a single webapp by utilizing HTML-Imports. However there are several `global` dependencies which need to be shared between apps

 - zone.js can only be started once
 - routing requires url-changes
 - Browser-stuff like cookies, sessionstorage, etc...

There are several articles in the net on how to bootstrap multiple angular-modules but they all refer to multiple modules in the same core-app, which in turn means they all are running on the same framework-version and an update means you have to rebuild and deploy the whole monolith.

**Is there any solution other than &quot;`iframes`&quot; to get multiple Angular (5) Apps running on the same Page?**

Angular and Micro-Frontends

If you go for a **microservices architecture** in your organization, they can share configuration via [zookeeper][1] or its equivalent. However, how should the various services share a common db schema? common constants? and common utilities?

One way would be to place all the microservices in the same code repository, but that would contradict the decoupling that comes with microservices...

Another way would be to have each microservice be completely independent, however that would cause code duplication and data duplication in the separate databases each microservice would have to hold.

Yet another way would be to implement functional microservices with no context\state, but that&#39;s usually not realistic and would push the architecture to having a central hub that maintains the context\state and a lot of traffic from\to it.

**What would be a scalable, efficient practical and hopefully beautiful way to share code and schema between microservices?** 

  [1]: http://zookeeper.apache.org/

All Microservices Solutions on Gang of Coders

Total of 22 Microservices Solutions

Microservices with shared database? using multiple ORM's?