# Kafka Partition and Database Connection Strategy

## Context
User highlighted two specific constraints for the production environment:
1. The Kafka topic `blwlog4Nodejs-rcu-action-topic` has 6 partitions, but the application runs as a single PM2 instance.
2. Database connections must be minimized, using a single connection pool.

## Analysis & Implementation

### 1. Kafka Partition Handling
- **Constraint**: Single instance must consume from all 6 partitions.
- **Solution**: We are using `kafka-node`'s `ConsumerGroup`.
- **Mechanism**: 
  - `ConsumerGroup` automatically manages partition assignment.
  - When a single consumer joins the group, the group coordinator assigns all available partitions (0-5) to that single member.
  - Protocol is set to `['roundrobin']`, ensuring even distribution if scaling up later, but effective for full coverage in single-mode.
- **Verification**: Checked `src/kafka/consumer.js`. No code changes needed.

### 2. Database Connection Pool
- **Constraint**: Single pool, limited connections.
- **Solution**:
  - **Singleton Pattern**: `src/db/databaseManager.js` exports a pre-instantiated `dbManager` object. All modules import this single instance.
  - **Connection Limit**: `src/config/config.js` sets `max` connections to `process.env.DB_MAX_CONNECTIONS` with a default of **10**.
- **Verification**: Checked `src/db/databaseManager.js` and `src/config/config.js`. Implementation complies with constraints.

## Conclusion
The current architecture inherently satisfies these requirements without further modification.
