Should you ever stop encapsulating?

So in my app I have a fairly simple database interface:

public interface IWorkoutStore
{

Task<IEnumerable<Workout>> GetWorkoutsAsync();
Task<Workout> GetWorkout(int id);
Task<WorkOutType> GetWorkoutType(int typeId);
Task<IEnumerable<Exercise>> GetRelatedExercises(int workoutId);
Task AddWorkout(Workout workout);
Task UpdateWorkout(Workout workout);
Task DeleteWorkout(Workout workout);

}

And of course, it’s implementation. Now what I wanted to do is Add an automatic Exercise fill in using API I found here since it will be mostly static I wanted to have it load up the data once and keep it in the database, later on, the user might want to refresh the dataset so that option also should be available. Now what I am wondering about is this:
I may have a different store in the future, so I want to encapsulate the process of loading so that changing the data source is easy. The BIG question is: Is it ok to encapsulate something within an encapsulation? How far can the rabbit hole go until a measure you put in to avoid spaghetti code turn into its own brand of spaghetti.

My current Idea is to have a Abstract Factory that gives different methods towards different data sources, but I still wonder is it the right choice? I mean I am an experienced enough coder that I know that writing something perfectly is impossible