Technical Task: Reliable Event-Driven Architecture

Objective

Build a fault-tolerant user registration flow using Microservices. The system must guarantee that every registered user eventually gets a "Welcome Task" created, even if the message broker (RabbitMQ) is down during the registration request.

Tech Stack

• Services: Node.js (Express)
• Database: MongoDB (Mongoose) - Configured as a Replica Set to support Transactions.
• Broker: RabbitMQ
• Infrastructure: Docker & Docker Compose

---

🏗️ The Architecture

The system implements the Transactional Outbox Pattern to ensure data consistency across distributed services.

1. Auth Service (The Producer)

• Endpoint: POST /api/v1/auth/register (email, password)
• Logic:
  • Starts a MongoDB Session (Transaction).
  • Creates a User document in the users collection.
  • Creates an Outbox document containing the event payload USER_REGISTERED in the outbox collection.
  • Commits the Transaction. If any operation fails, the entire transaction rolls back.
• The Relay (Background Worker):
  • A separate background loop polls "pending" events from the outbox collection.
  • Publishes events to RabbitMQ.
  • Updates the outbox status to SENT only after receiving an Acknowledgment (ACK) from RabbitMQ.
• Detailed Documentation: Auth Service README

2. Todo Service (The Consumer)

• Logic:
  • Listens to the user_registered_queue.
  • Creates a default "Welcome to the App" todo item for the registered user ID.
  • Idempotency: Utilizes a processed_events collection with a unique index on eventId to ensure that duplicate messages do not result in duplicate tasks.
• Detailed Documentation: Todo Service README

---

🚀 Getting Started

Prerequisites

• Docker and Docker Compose installed.

Installation & Setup

1. Clone the repository:

   git clone <repository-url>
   cd todo-microservice

2. Run with Docker Compose:

   docker-compose up -d --build

   Note: This will orchestrate the Auth Service, Todo Service, RabbitMQ, and a MongoDB Replica Set.

3. Access the Services:

   • Auth Service: http://localhost:4001
   • Todo Service: http://localhost:4002
   • RabbitMQ Management: http://localhost:15672 (Guest/Guest)

---

🧪 Reliability Testing: Simulating Failures

To verify the fault tolerance and reliability of the system, follow these scenarios:

Scenario 1: Broker (RabbitMQ) is Down

1. Stop RabbitMQ: docker stop rabbitmq
2. Register a User: Send a POST request to http://localhost:4001/api/v1/auth/register.
   • Result: The registration succeeds, and the user is saved. The outbox shows a PENDING event.
3. Start RabbitMQ: docker start rabbitmq
4. Verification: After RabbitMQ comes back online, the Relay service will detect the pending event, publish it, and the Todo Service will eventually create the "Welcome Task".

Scenario 2: Consumer (Todo Service) is Down

1. Stop Todo Service: docker stop todo-service
2. Register a User: Perform a registration in the Auth Service.
3. Check RabbitMQ: View the management UI; you will see the message waiting in the queue.
4. Start Todo Service: docker start todo-service
5. Verification: The Todo Service will consume the waiting message immediately upon startup and create the task.

Scenario 3: Duplicate Message Delivery (Idempotency)

1. Manually publish the same eventId payload to the RabbitMQ queue twice.
2. Verification: Check the Todo database. Only one "Welcome Task" should exist for that event ID, as the service rejects the second attempt via the processed_events uniqueness check.

---

📁 Deliverables

1. Source Code: Clean modular structure with ES6+ syntax.
2. Docker Configuration: Complete docker-compose.yml with MongoDB Replica Set support.
3. API Logic: Full implementation of the Transactional Outbox and Event Consumption.