Teams should switch models without code changes. What do you design?
Why D is the answer
An abstraction layer that reads the model from configuration
An abstraction layer that reads the model name from configuration lets teams change models with no code change.
In detail
- An abstraction layer reads the model from configuration.
- Keep model-specific prompts in configuration too.
Use case
An illustrative scenario, not a real incident.
A team switches models by changing one configuration value, with no release.
See it in different ways
flowchart LR A["Application"] --> B["Model abstraction layer"] C["Configuration"] --> B B --> D["Model A"] B --> E["Model B"]
sequenceDiagram participant S as Service participant L as Abstraction layer participant C as Configuration participant M as Model S->>L: Request L->>C: Which model? C-->>L: Model ID L->>M: Call M-->>S: Response
sequenceDiagram participant P0 as App participant P1 as Abstraction layer participant P2 as Configuration participant P3 as Model P0->>P1: Generate P1->>P2: Which model? P1->>P3: Call chosen model
Key point: Abstract the model behind configuration.
Why the other options are wrong
- A. A manual runbook that engineers follow to edit each Lambda function
- A runbook is manual.
- B. A separate application for each model that the team might use
- One app per model multiplies the work.
- C. A model ID hard-coded in each service, changed through a new release
- Hard-coded IDs need a release.