content_image/994622.jpg
That’s not to say that every IBM MQ system behaves like this, thought around the design and how applications use it to maximize the scalability and availability is required. Small deployments of IBM MQ in the past commonly focused on a single queue manager approach. 

Figure 9-17 shows single IBM MQ instance topology. 

<img src='content_image/994622.jpg'>

With this model steps, you can take steps to make that single queue manager as available as physically possible. Perhaps you would use one of IBM MQ’s hi gh availability capabilities, such as multi-Instance described in 9.2.2, “Multi-instance queue managers in containers” on page 583. This does not avoid those times when the queue manager needs to be restarted or reconfigured. At those times, you have an outage as the queue manager fails over, even if just for a few seconds. 

Continuous availability looks to avoid an outage of the whole messaging system differently, an architecture that avoids a single queue manager as the route for all messages. Many clients have built continuous available IBM MQ systems to do just that, these use multiple active queue managers and distribute the messaging workload across them. And it is not enough just to worry about the messaging layer, applications also need to remove any single points of failure, so that means multiple active instances of the applications as shown in Figure 9-18 on page 588. 

