You don't share code between the services, services call each other. This mean you will have some code that is duplicated between services, that's normal. One

You don't share code between the services, services call each other. This mean you will have some code that is duplicated between services, that's normal. One microservice should never directly modify data another microservice manges, each service should manage and maintain its own data source to keep the responsibilities clear. There are some other methods for certain common functionality, like using sidecars etc. There are pros and cons of it all, just depends on the situation and beliefs of the architect. IME, most companies aren't ready for, nor do they need, a true full scale microservices architecture. Instead a hybrid approach is more likely to be successful, where certain key services are isolated but the rest of the app can still be more of a monolith. The trick is identifying those key services and separating them out. One I almost always separate as a start is authentication/authorization, done properly it will keep that code very focused, clean and more secure. Other likely candidates are any service that might ingest large amounts of data but is focused, this will let you scale it independently to support load and growth but not force you into a complete microservices environment which can be daunting to manage at first.