Эта проблема состоит из 2 частей:
Архитектура: у меня есть таблица с «приложениями». Эти заявки передаются в стороннюю службу, где для «одобрения» или «отклонения» требуется около одного или двух дней, в то время как состояние «ожидает рассмотрения». У сторонней службы есть конечная точка ведения журнала, где они постоянно публикуют статусы приложений, когда они «одобрены» или «отклонены».
Алгоритм: конечная точка запрашивается по параметру запроса приложения (int, сгенерированному при отправке приложения) и метке времени, и возвращает список состояний. Этот список, который возвращается, начинается с ближайшего опубликованного идентификатора / метки времени, основываясь на параметрах, которыми вы достигли конечной точки, и имеет размер, основанный на int, который вы предоставляете конечной точке: https://endpoint? Id = & listSize = & dateTime =
Мои вопросы:
Архитектура: Должны ли я поставить все эти приложения (с состояниями "в ожидании" и "одобрено"") в 1 таблицу и иметь столбец состояния, или я должен разбить это на 2 таблицы и иметь таблицу для всех" утвержденных "приложений и другую таблицу для всех" ожидающих рассмотрения "приложений? (И, может быть, даже таблица для всего «отклоненного» приложения.)
Алгоритм: каков наилучший способ (шаблон проектирования) для непрерывного опроса конечной точки регистрации, чтобы реализоватьследующее состояние, а затем выполнить необходимое обновление на основе окончательного статуса этих приложений?
Общая картина:
Существует ли уже этот шаблон проектирования и существуют ли решения для этого?
Предоставляет ли AWS что-то созданное для этого и / или рекомендуется ли программное обеспечение, такое как Celery, для выполнения таких рутинных задач регистрации и обновления?