How to deal with shared models in micro service architectures

Question

My goal is to create an architecture in which services should be able to deploy independent of each other and are completely autonomous, but what do you do when you have 2 servi

Answer 1

... there are calls to the socket server that needs to check that validity of that ID, thus, needs to read from DB. This two services will have to share the model of A in order to map it to an object, ...

Well - no, they do not need to share code! The only thing they actually need, is a common understanding of the schema of the DB (I assume you're using MongoDB). Whether that understanding is coming from shared class definitions in shared libraries or from duplicated class definitions in separate libraries does not really matter. Many developers will now start screaming at me for violating the DRY (Don't repeat yourself) principle, but with microservices many things are different to what we're used to!

In her answer, Priti Singh states that:

Two microservices should not share same data model

which in correct in a microservice context and considered good practice! Let me show you why:

In the microservice pattern, services should be independant of other sevices and have well-defined interfaces. Having two different services reading the same DB makes that DB another "service" (I KNOW, weird, right?!?). By definition this database now needs a well-defined interface - which is kind of difficult in a schemaless DB ;-) Another reason not to make a DB act like a service is, that changes in one service will always have some influence on the other service accessing the data. This means, changing the "schema" on one service might force you to change another service as well, just to keep your system running! That's a headache when you consider a full-blown microservice system with >100 services.

That is why your second idea:

... or should I make only service1 able to read from DB and then make the second one talks to service 1?

is much better. Keep your database hidden behind a service with a well-defined interface that can be versioned. Like this you can refactor inside service 1 as your heart desires without necessarily influencing other services. Once you need to make a breaking change on your interface - give it a new version and start migrating other services to use the new interface.

The underlying controversy in your question is the one of Coupling vs. Duplication. Sharing an interface definition and database is coupling (the wakes-you-up-at-night-after-a-small-change kind of coupling) but duplicating the database schema to both services is duplication. I believe that coupling will kill you long before duplication does, but taking your second approach, having the http-service access the socks-service which then accesses the database should remove duplication as well as reduce coupling!

Let me know if this was helpfull!