Databases are not very good at information hiding, which is quite plausible, because their job is to actually expose information. But this makes them a lousy tool when it comes to encapsulation. Why do you want encapsulation?
Scenario: you tie a couple of components to an RDBMS directly, and you see one particular component becoming a performance bottle-neck for which you might want to denormalize the database, but you can't because all other components would be affected. You may even realize that you'd be better off with a document store or a graph database than with an RDBMS. If the data is encapsulated by a small API, you have a realistic chance to reimplement said API any way you need. You can transparently insert cache layers and what not.
Fumbling with the storage layer directly from the application layer is the diametrical opposite of what the dependency inversion principle suggests to do.
Ok, so the classic problem with your setup is that the high volume calls slow down, or break the low volume calls. or in your case the Services slow down the Users.
The solution is to split the service into two as you have, sort of, done. You can then either scale up or throttle the Service without affecting the Users
As you point out its not recommended to share code across services. I guess you have it left over from when they were one service. And as you say, they are both using the same datalayer.
Now there IS something wrong. But its not so much the shared code as the fact that you are still sharing a database.
Being on the same db means that the high traffic calls can still affect the Users. If you moved them off you would presumably no longer have any shared code.
Sharing code in of itself may give you some maintenance difficulties and you should try to refactor it out if possible. But its not the root of the problem.
You may find that if the high volume service hits performance limits due to cpu or memory rather than database calls then you have already solved your issues by splitting the service at the code level. In that case sharing datalayer code is not a bad thing.
Best Answer
You don't.
Creating a separate database for each service helps to enforce domain boundaries, but it's only one approach. There's nothing stopping you from having all your services share the same database.
As long as your services behave and don't do unexpected things to data owned by other services, you'll be fine.
I don't know what you read, but you should be aware that there are many differing opinions on microservices architecture. Here's a good blog post on the topic.