Advantages:

— Flexibility and expandability: Allows for easy introduction of new types of products without changing existing code.
— Reducing dependencies: The Factory Method reduces the direct dependency between classes that create and use objects, making code modification and testing simpler.
— Ease of maintenance and updates: Code using the pattern is easier to maintain and update, as adding a new type of product often doesn’t require changes to the existing code that uses the factory.

Disadvantages:

— Complex architecture: Using Factory Method can complicate application architecture, especially when used unnecessarily or in simple scenarios.
— Code bloat: Creating many factory methods and classes can overload the code, making it hard to understand, particularly for new developers.
— Performance issues: In some cases, particularly with incorrect implementation, Factory Method can affect application performance due to additional method calls and object creations.
— Debugging difficulty: Following this pattern can make debugging harder since the actual object creation is hidden within the factory method, complicating error tracking.
— Need for careful planning: Effective use of Factory Method requires detailed planning and understanding of when and what objects should be created. Planning errors can lead to incorrect or excessive implementation.
— Limited flexibility in some scenarios: While Factory Method provides flexibility in object creation, it can be limited in scenarios requiring very dynamic or conditional object creation.
— Not suitable for simple applications: For small or simple applications with a relatively static structure, using Factory Method might be unnecessary and complicate the project.

...when a user wants to navigate to other routes having pending data changes in the current page...

The Saga pattern addresses this by breaking a transaction into smaller, local transactions handled by different services.

— Orchestration-Based Saga: A single orchestrator (arranger) manages all the transactions and directs services to execute local transactions.
— Choreography-Based Saga: All the services that are part of the distributed transaction publish a new event after completing their local transaction.

— Booking Service: Starts the process by reserving a room. This is the first local transaction. Once successful, it sends a message to the Payment Service to process the payment.
— Payment Service: Receives the message and processes the payment. If the payment is successful, it commits its local transaction and informs the Booking Service and Notification Service.
— Notification Service: On receiving confirmation of successful payment, it sends a booking confirmation email to the user.
— Handling Failures: If the Payment Service encounters an issue (e.g., payment decline), it returns a failure message to the Booking Service. The Booking Service then executes a compensating transaction to cancel the room reservation, ensuring the system returns to its original consistent state.

— Node.js project with necessary dependencies (express, amqplib, nodemailer, mongoose, dotenv) installed.
— RabbitMQ server running locally or remotely.
— Email server or service for the Notification Service (e.g., Nodemailer with SMTP or an email API service).