python - Run two processes in a single docker container or two containers connecting to the same DB? -

i need develop application listens kafka topic , saves data db (cassandra). high density stream of data saving data resource expensive. once data saved queried , exposed through rest api.

i see 2 options, both of them have downsides:

option 1
create 2 services, each 1 in separate docker container. 1 run kafka listener process in python , other 1 flask web server.
advantages: every container runs 1 process
downsides: both services connect same db, not ideal according microservices pattern architecture, services not decoupled.

option 2
run both, kafka listener , web service in 1 container.
advantages: 1 service connect db.
downsides: more 1 process running in single docker container, , 1 of them (saving , updating) lot more resource expensive other, not scale uniformly.

is there way go doesn't involve moving monolithic architecture? or 1 of them best practice?

go option 1. use docker compose setting containers:

• one "service" kafka consumer.
• one "service" rest api process.
• if want containerize database, add cassandra container well.

using docker compose allow spin things 1 command, can have dependencies , links (dns name resolution) between containers, centralized logging, etc. - it's ideal cases yours.

separating containers allow scale, control lifecycle of applications, , allow start/stop/update each application individually. also, need run single process per container, proven , recommended best practice. makes controlling lifecycle of container , application easier, , keeps container lean , easier manage.

example: do if kafka listener goes down , rest api keeps running? fix this, have restart whole container (unless want ssh container , restart 1 of processes). 1 process per container makes trivial - restart container.

the fact both pointing same database irrelevant - you'll have live if both services use same data. alternative synchronize between 2 databases (one kafka listener writes to, , 1 rest api). add more complexity , overhead. if clean design, can still add later if see value in separating data - wouldn't worry initially.