Есть некий сервис, куда мы обращаемся за данными. Для наглядности, пусть это будет Redis, а читаем мы из него профили пользователей. Проблема заключается в том, что приходится делать это с очень большой частотой - тысячи, а то и десятки тысяч мелких запросов в секунду. Из-за этого сильно страдает latency приложения. А у Redis-а тем временем есть метод для чтения не единичных элементов, а сразу целой пачки (Client.MGet). Необходимо разработать решение (библиотеку), которое будет получать у приложения ключи (идентификаторы пользователей), объединять их в batch-и и обращаться к внешнему сервису по достижении одного из двух параметров: достигнут лимит ключей в батче или прошло какое-то время с момента получения библиотекой первого ключа (оба параметра задаются программистом). Все горутины приложения, которые запрашивают у библиотеки данные по ключу должны висеть и ждать пока не выполнится batch (тот куда попали их ключи) и после этого получить необходимые данные или ошибку (данные по ключу не найдены, произошла какая-то ошибка при обращении к сервису и тд). Замечу, что старт выполнения batch-а должен быть неблокирующим, т.е. если появятся новые горутины, то их не надо заставлять ждать пока обработается текущий батч и после этого ждать пока не накопится новый батч.
Если работать с Redis неудобно или нет опыта работы с ним, то можно выбрать любой сервис, который удобен - sql, nosql базы, aerospike, ... Важен не сам сервис и работа непосредственно с его API, а механизм построения батчей по ограничениям (размер батча или диапазон сбора ключей) и их асинхронная обработка. А может быть получится абстрагироваться от конкретного сервиса, чтобы библиотека могла работать с разными сервисами?
И пожалуй стоит задуматься над тем, что произойдёт если внешний сервис начнёт работать медленно и количество батчи начнут накапливаться вследствие этого.