It looks like both the scenarios are pretty much the same. Single-Point-Of-Failure.

In your first scenario, your BDD service might crash, on the other it's the database, there's not much of a difference.

Microservices are basically systems, that need to manage pretty much everything of their own, which means they require a dedicated data storage.

Each microservice is suppose to run independently, so having every microservice pointing to a single DB, doesn't make sense.

Read this article for more details on microservice martinfowler.com/articles/microservices.html

Hope this helps!

Using separate database for every microservices will reduce the dependency, and make them separately scalable.

In first approach your microservices BDD is a single point of failure, means if BDD fails your entire system is down , as already mentioned.

In second one , though MS are directly connecting with db , your db may become a bottleneck at later stages. When load/ volume of transcations / reads are high one one MS and low on other and your only option is to scale database as a whole instead of scale only the part you need.

However, if resource consumption is a problem you can stick with single database and can introduce in-memory databases like Redis in between your MS and db to cache data and avoid direct db reads. This will keep certain part of application live in case of db downtime or crash.