Why do Databases fail? AntiPatterns to avoid !

Databases are often used to store various types of information, but one case where it becomes an a problem is when being used as a message broker.

The database is rarely designed to deal with messaging features, and hence is a poor substitute of a specialized message queue. When designing a system, this pattern is considered an anti pattern. 

Here are possible drawbacks:

• Polling intervals have to be set correctly. Too long makes the system is inefficient. Too short makes the database undergo heavy read load.
• Read and write operation heavy DB. Usually, they are good at one of the two.
• Manual delete procedures to be written to remove read messages.
• Scaling is difficult conceptually and physically.

Disadvantages of a Message Queue:

• Adds more moving parts to the system.
• Cost of setting up the MQ along with training is large.
• Maybe be overkill for a small service.

It is important to be able to reason why or why not a system needs a message queue. These reasons allow us to argue on the merits and demerits of the two approaches.

However, there are blogs on why Databases are perfectly fine as message queues too. A deep understanding of the pros and cons helps evaluate how effective they would be for a given scenario. 

In general, for a small application, databases are fine as they bring no additional moving part to the system. For complex message sending requirements, it is useful to have an abstraction such as a message queue handle message delivery for us.

Publisher Subscriber Model

Microservices benefit from loose data coupling, which is provided by a publish subscribe model. In this model, events are produced by a publishing service and consumed by downstream services.

Designing the micro service interactions involves event handling and consistency checks. We look into a pub-sub architecture to evaluate it's advantages and disadvantages compared to a request response architecture.

This type of architecture relies on message queues to ensure event passing. An example would be rabbitMQ or Kafka. The architecture is common in real life scenarios and interviews.

If there is no strong consistency guarantee to made for transactions, an event model is good to use in microservices. Here are the main advantages:

• Decouples a system's services.
• Easily add subscribers and publishers without informing the other.
• Converts multiple points of failure to single point of failure.
• Interaction logic can be moved to services/ message broker.

Disadvantages:

• An extra layer of interaction slows services
• Cannot be used in systems requiring strong consistency of data
• Additional cost to team for redesigning, learning and maintaining the message queues.

This model provides the basis for event driven systems.