Tech debt: Config.load() scaling — consider splitting config by service #184

Closed
opened 2026-03-11 07:43:13 +01:00 by shahondin1624 · 2 comments

Background

Found during periodic refactoring review after 5 completed stories.

Problem

As more services are added, Config.load() patterns may accumulate more fields and env vars. Currently manageable but worth monitoring.

Suggested Fix

Consider splitting config into per-service config modules if the number of config fields grows beyond ~15-20, or use a config framework that supports hierarchical config.

Labels

Type: refactor, Priority: low

## Background Found during periodic refactoring review after 5 completed stories. ## Problem As more services are added, `Config.load()` patterns may accumulate more fields and env vars. Currently manageable but worth monitoring. ## Suggested Fix Consider splitting config into per-service config modules if the number of config fields grows beyond ~15-20, or use a config framework that supports hierarchical config. ## Labels Type: refactor, Priority: low
Author
Owner

This has progressed: Config.load() is now 180 lines of boilerplate with 9 sub-config sections. Created #199 with a concrete fix proposal (generic _load_dataclass helper). This issue can be closed once #199 is addressed.

This has progressed: `Config.load()` is now 180 lines of boilerplate with 9 sub-config sections. Created #199 with a concrete fix proposal (generic `_load_dataclass` helper). This issue can be closed once #199 is addressed.
Author
Owner

Resolved by #199 (PR #215). Config.load() boilerplate has been replaced with a generic _load_dataclass() helper, reducing the method from ~180 to ~30 lines. The scaling concern is no longer relevant.

Resolved by #199 (PR #215). Config.load() boilerplate has been replaced with a generic `_load_dataclass()` helper, reducing the method from ~180 to ~30 lines. The scaling concern is no longer relevant.
Sign in to join this conversation.