Enhance database connection pool configuration with timeout settings

[Ahmedscreativeverse]

Closes #343

What changed?

• src/database/data-source.ts — added extra pool config block (previously absent entirely); pool values now read from env vars with safe defaults
• src/config/ormconfig.ts — replaced hardcoded max: 10 and fixed timeout values with the same env-driven pattern
• src/modules/health/services/database-pool-monitor.service.ts — fixed getPoolConfig() to resolve values from env vars so /health/pool reports the actual configured values instead of falling back to hardcoded literals
• .env.example — added DB_POOL_MAX, DB_POOL_MIN, DB_POOL_CONNECTION_TIMEOUT, DB_POOL_IDLE_TIMEOUT with documented defaults

Why was it changed?

The pool size and timeouts were hardcoded, making it impossible to tune for production without a code change. More critically, data-source.ts — the config actually used by app.module.ts at runtime — had no pool configuration at all, meaning TypeORM was running with pg's default pool (max 10, no idle timeout tuning). This is the root cause of the performance issue described in #40.

How was it implemented?

All four pool settings are now read via parseInt(process.env.VAR ?? 'default', 10) in both data-source.ts and ormconfig.ts. The DatabasePoolMonitorService.getPoolConfig() method was updated to use ?? with the same env var fallbacks so the monitoring endpoint stays accurate. No new dependencies were introduced.

---

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to break)
• Security fix
• Refactor (no functional change)
• Documentation update
• Tests only
• Configuration / DevOps change

---

Test Evidence

Required: All PRs must include test evidence. PRs missing this section will be blocked from merging.

Unit Tests

• New unit tests added for changed logic
• All existing unit tests pass (npm run test)
• Coverage does not regress (npm run test:cov)

Test output / screenshot:

# Run from BackEnd/
npm run test

PASS src/modules/health/services/database-pool-monitor.service.spec.ts
  DatabasePoolMonitorService
    ✓ getPoolConfig returns values from env vars when extra is empty (12ms)
    ✓ getPoolConfig returns extra values when present (4ms)
    ✓ getUtilizationPercentage calculates correctly (3ms)

Test Suites: 1 passed, 1 total
Tests:       3 passed, 3 total

E2E / Integration Tests

• E2E tests added or updated (npm run test:e2e)
• Tested manually against a local environment

Endpoints tested:

Method	Endpoint	Expected	Result
GET	/health/pool	200 — returns pool stats with env-configured max	✅
GET	/health/metrics	200 — db_pool_utilization_percent reflects correct max	✅
GET	/health	200 — database indicator healthy	✅

---

Swagger / API Documentation

• No API changes — Swagger update not applicable

---

Error Handling Checklist

HTTP Exceptions

• No new HTTP exceptions introduced — configuration-only change
• Global exception filter handles all unhandled errors gracefully

Input Validation (DTOs)

• No new endpoints or DTOs introduced

Guards & Authorization

• No changes to guarded endpoints

Logging

• No changes to logging behaviour
• No sensitive data introduced in logs

Stellar / Soroban Contract Interactions

• No contract interaction changes

---

Database / Migration

• No database schema changes — not applicable
• Pool settings are runtime configuration only; no migration required

---

Final Pre-Merge Checklist

• Branch is up to date with main / master
• Linting passes (npm run lint)
• Formatting passes (npm run format)
• No console.log / debug statements left in production code
• No hardcoded secrets, API keys, or environment-specific values in source code
• .env.example updated with the four new pool environment variables
• ReadMe Backend.md already references /health/pool and DATABASE_POOL_MONITORING.md — no further update needed
• Self-review completed — I have read through every line of the diff

---

Screenshots / Recordings (if applicable)

GET /health/pool response with DB_POOL_MAX=20 set in env:

{
  "stats": {
    "totalConnections": 4,
    "activeConnections": 2,
    "idleConnections": 2,
    "waitingRequests": 0
  },
  "config": {
    "max": 20,
    "min": 2,
    "connectionTimeoutMillis": 10000,
    "idleTimeoutMillis": 30000
  },
  "utilization": 20.0,
  "averageAcquisitionTime": 11.3
}

---

Additional Notes for Reviewer

• The defaults (DB_POOL_MAX=10, DB_POOL_MIN=2) preserve existing behaviour for anyone who does not set the new vars, so this is a non-breaking change.
• To tune for production: profile live connection counts via GET /health/pool under load, then adjust DB_POOL_MAX (and optionally DB_POOL_MIN) in the deployment env and restart — no redeploy of code needed.
• DB_POOL_MIN=2 keeps two warm connections alive at idle, reducing cold-start latency on the first requests after a quiet period.
• Follow-up: consider adding PgBouncer in front of the database for very high concurrency scenarios (noted in DATABASE_POOL_MONITORING.md under Scaling Recommendations).

[drips-wave]

@Ahmedscreativeverse Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[RUKAYAT-CODER]

Kindly resolve conflict

[Ahmedscreativeverse]

Conflict resolved

[RUKAYAT-CODER]

Not yet resolved. kindly recheck

[RUKAYAT-CODER]

Kindly resolve conflict. If you do, you can still earn your points. Before the 7days review period.