Timeline for Two processes in a single docker container or two services connecting to the same db?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 10, 2017 at 18:16 | comment | added | closeparen | My employer recognizes services as containing one or more applications, typically cut from a monorepo. Each application has its own entrypoint, but the expectation is that applications of a service share code and data. So in this case you have a scraping service with crawler, formatter, ingestion, and API components. | |
| Jun 10, 2017 at 18:14 | comment | added | closeparen | I would caution against this kind of dogmatic commitment. You will often have different access patterns around the same data (i.e. streaming ingestion and RPC, or even different groups of RPC endpoints) such that it makes sense to run distinct processes that access the same data. The monolith smell starts to creep in when services that have wholly separate responsibilities and datasets are sharing a DB. Several microservices can (and should!) be cooperating components of the same subsystem with the same dataset. Don't stick your users table on it, but other scraping components are fine. | |
| Mar 12, 2017 at 17:23 | comment | added | mgw854 | I wouldn't say it's not an anti-pattern, just that it's an option. If you have to share a database, you just have a distributed monolith. | |
| Mar 12, 2017 at 14:41 | history | edited | Tristan | CC BY-SA 3.0 | added 168 characters in body |
| Mar 12, 2017 at 11:24 | history | answered | Tristan | CC BY-SA 3.0 |