Задумался, каким образом в крупных интернет магазинах формируется ссылка с

параметрами, наверняка они перепробовали кучу способов и выбрали оптимальный.

Например, берем Amazon, Ebay, Wildberries, Aliexpress, Tmall, Yandex Market.
Что мы видим? После каждого изменения фильтров изменения записываются в адресную строку, делается get-запрос к бекенду и обновляется страница. Сортировка, пагинация при большом количестве данных тоже выполняются серверно и добавляются в этот запрос.

Каждый фильтр должен добавлять и изменять свой параметр в адресной строке.
Если каждая отдельная функция фильтрации не знает, какие фильтры уже применены, то у нас будут в адресной строке и в самом запросе к бекенду плодиться одинаковые поля фильтрации, что недопустимо.
Поэтому потребуется получать все уже примененные параметры, парсить их в объект, изменять относящееся к нему свойство и записывать обратно в адресную строку?

Фильтров всегда много
1 вариант. Хранение настроек фильтрации можно реализовать с помощью глобальной переменной - объекта настроек фильтрации paramsObj, который через стандартный метод (или это конструктор)new URLSearchParams(paramsObj); превращается в параметры адресной строки. Тогда перезаписывать адресную строку потребуется всего один раз, при отправке запроса (понятно, что запрос отправляется после каждого изменения фильтров, но здесь он в коде будет в одном месте только - в месте отправки запроса). Минус - глобальные переменные - это засорение глобальной области видимости, да и я когда-то пробовал вынести создание этой переменной в отдельный модуль ничего не заработало.

2 вариант.
Хранить в localstorage.
Вернемся к задаче: После перезагрузки страницы параметры фильтрации не сбрасываются, думаю, что это потому что ф5 собственно адресную строку не трогает и все сохраняется, так и надо.
При этом при входе с новой вкладки на ту же страницу без параметров - параметров в адресной строке нет.

При использовании localstorage для хранения объекта настроек фильтрации после нового входа на страницу будут сразу применяться старые настройки, а этого нам не нужно. Лечится легко - чистить localstorage при каждой загрузке страницы.
Ни в одном из рассмотренных примеров в localstorage не обнаружено настроек фильтрации, значит они там не хранятся. Поэтому вариант с localstorage дальше не рассматриваем

Еще не рассматривал cookies, архитектурно подход с ними звучит идентичным с localstorage. Осложняется те, что никогда с кукиз не работал и не особо представляю, что это такое

3 вариант
Можно использовать в качестве хранилища саму адресную строку - считывать ее данные с помощью стандартных свойств и методов наподобие window.location, парсить, добавлять/изменять нужное свойство и записывать обратно. Звучит немного костыльно, но не дублирует функционал и неплохо архитектурно.

По быстродействию и нагрузке на клиентское железо идей нет.

Если использовать вебсокеты, а конкретно нравится socket.io, то это влияет на схему? Необходимо ли сразу добавлять реализацию response-request для сокетов?

зачем для этого сокеты я ащ не понял ну и переменная - тоже. плюсы как раз того, что оно все в url, вы можете скинуть это кому-то, и он сможет сразу же увидеть ту же картину. тут переменным откуда взяться?

все 3 варианта должны работать одинаково и поддерживать параметры url, это же зависит от типа запроса, get/post сокеты - уже отдельная тема - реализация, для быстро обновляющихся на сервере данных они дают хороший прирост

фильтр постом? у вас graphql?

вы хотите в лайве на страницу пихать то новое, что подходит под фильтр? оо

в случае новостного аггрегатора - да