What are the benefits of spreading the various services of a multi-tiers application over several user-define bridges? I have a simple system made of a database backend, several instances of a web application and a load balancer. Each service is running in its own Docker container, all of them being hosted on the same physical server. The load balancer listens on the port 80 which is mapped to the same port on the host. All ingress/egress traffic is supposed to pass through that load balancer.

Currently, all those containers are attached to a single user-defined bridge.

I read it would be better to connect the load balancer and the app instances through one bridge, and the app instances and the database through a second one. Instinctively, it makes sense to avoid putting the DB on the public-facing bridge. But objectively, in a dockerized environment, what are the benefits of using two bridge networks instead of only one here? Which kind of threats is mitigated by doing so?
Your updated question completely changed my understanding :)

Since the db is on a user-defined bridge in both cases, the advantages of using user-defined vs legacy/default bridges discussed in the doc section you referenced (which are applicable in both cases) aren't what differentiates the 2 cases. From that perspective they're equivalent.

Original Answer:

I think most/all of the differences between the legacy/default bridge and the user-defined ones listed in the doc section you referenced are pretty objective advantages :)

For your particular question, in User-defined bridges provide better isolation and interoperability between containerized applications we see:


  Using a user-defined bridge, only the web port needs to be opened, and
  the database application doesn’t need any ports open, since the web
  front-end can reach it over the user-defined bridge


Since in such case the db doesn't have open ports it can't be accessed from the outside, so all threats associated with having the db reachable from the outside are avoided.