From 419ab28bcbd09870abe66d0f270c118782da40cd Mon Sep 17 00:00:00 2001 From: Nuradil Alymkulov Date: Thu, 20 Jun 2024 13:25:43 +0300 Subject: [PATCH 1/3] Create infra.md --- cases/infra.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 cases/infra.md diff --git a/cases/infra.md b/cases/infra.md new file mode 100644 index 0000000..025f6c2 --- /dev/null +++ b/cases/infra.md @@ -0,0 +1,20 @@ +## Описание кейса +Спроектировать сервис потоковой обработки. +## Задача +1. Сервис принимает тяжелые данные (100+ MB) за раз (эндпоинт `/submit`) +2. Данные должны быть обработаны в несколько шагов (parallel & serial) +3. Необходимо оптимизировать потребление памяти / CPU +4. Обработка данных должна быть идемпотентной +5. Эндпоинт приема данных должен работать быстро (<10 seconds) +6. Метаданные должны храниться персистентно + +## На что обращаем внимание +1. `/submit` должен использовать потоковую обработку для экономии памяти, хотя и больше времени занимает +2. Можно использовать celery, airflow, spark, etc. Но надо проверить знание основ потоковой обработки +3. Для идемпотентности можно использовать очереди, БД, redis/memcached, etc. Надо у любого выбранного метода выяснить минусы/плюсы +4. Как передаются данные на каждом шагу? S3, Redis, DB? +5. Знаком ли с концепцией ETL/ELT? +6. Как кандидат будет мониторить? +7. Как будет запускаться сервис? k8s, docker compose, AWS Lambda, etc.? +## Пояснения +1. From 65b8c394b676a9a7adb56d65ccde68ea223c3cfa Mon Sep 17 00:00:00 2001 From: Nuradil Alymkulov Date: Thu, 20 Jun 2024 13:40:57 +0300 Subject: [PATCH 2/3] Update infra.md --- cases/infra.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/cases/infra.md b/cases/infra.md index 025f6c2..4809e96 100644 --- a/cases/infra.md +++ b/cases/infra.md @@ -1,12 +1,15 @@ ## Описание кейса Спроектировать сервис потоковой обработки. ## Задача -1. Сервис принимает тяжелые данные (100+ MB) за раз (эндпоинт `/submit`) -2. Данные должны быть обработаны в несколько шагов (parallel & serial) +1. Сервис принимает тяжелые данные (json-serializable) (100+ MB) за раз (эндпоинт `/submit`) -> `input` +2. Данные должны быть обработаны в несколько шагов (каждый из шагов может вызывать внешний API): + 2.1. Обработка нескольких ключей (из `input`) независимо (пример: ключи `constraints`, `contracts`, `orders`) + 2.2. После п. `2.1.` результаты обработки `constraints`, `contracts` мерджятся в одну структуру и проводится дополнительная обработка (`contracts-constraints-result`) + 2.3. Последний шаг - обработка `contracts-constraints-result` и `orders` вместе и выдача результата -> `result` 3. Необходимо оптимизировать потребление памяти / CPU -4. Обработка данных должна быть идемпотентной +4. Обработка данных должна быть идемпотентной. 5. Эндпоинт приема данных должен работать быстро (<10 seconds) -6. Метаданные должны храниться персистентно +6. Метаданные из `input` должны храниться персистентно и отдаваться пользователю в эндпоинте ## На что обращаем внимание 1. `/submit` должен использовать потоковую обработку для экономии памяти, хотя и больше времени занимает From a306b0a8786e5f20e465cf3536ecfdad1cb1bf6d Mon Sep 17 00:00:00 2001 From: Nuradil Alymkulov Date: Thu, 20 Jun 2024 13:41:48 +0300 Subject: [PATCH 3/3] Update infra.md --- cases/infra.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/cases/infra.md b/cases/infra.md index 4809e96..2000af9 100644 --- a/cases/infra.md +++ b/cases/infra.md @@ -3,9 +3,9 @@ ## Задача 1. Сервис принимает тяжелые данные (json-serializable) (100+ MB) за раз (эндпоинт `/submit`) -> `input` 2. Данные должны быть обработаны в несколько шагов (каждый из шагов может вызывать внешний API): - 2.1. Обработка нескольких ключей (из `input`) независимо (пример: ключи `constraints`, `contracts`, `orders`) - 2.2. После п. `2.1.` результаты обработки `constraints`, `contracts` мерджятся в одну структуру и проводится дополнительная обработка (`contracts-constraints-result`) - 2.3. Последний шаг - обработка `contracts-constraints-result` и `orders` вместе и выдача результата -> `result` +- Обработка нескольких ключей (из `input`) независимо (пример: ключи `constraints`, `contracts`, `orders`) +- После предыдущего пункта результаты обработки `constraints`, `contracts` мерджятся в одну структуру и проводится дополнительная обработка (`contracts-constraints-result`) +- Последний шаг - обработка `contracts-constraints-result` и `orders` вместе и выдача результата -> `result` 3. Необходимо оптимизировать потребление памяти / CPU 4. Обработка данных должна быть идемпотентной. 5. Эндпоинт приема данных должен работать быстро (<10 seconds)