
Sharing an SQLite database across containers is surprisingly brilliant - vinnyglennon
https://medium.com/@rbranson/sharing-sqlite-databases-across-containers-is-surprisingly-brilliant-bacb8d753054
======
whack
Can someone explain the technical details around this? Specifically:

1) How are writes/updates propagated to all other containers/hosts? Is this
based on the assumption that the containers will only read from the database,
and not write to it? And that any writes being made externally, only need to
be deployed to new containers, and it is fine for existing containers to read
stale values?

2) Is there anything special about SQLite that enables this design? Or would
someone else be able to do the same thing with a config.json file that is then
read and parsed by each instance of the application?

3) I'm presuming that latency is vastly improved because real-time network
requests are avoided. Can the exact same result be achieved by eagerly
prefetching the config data at startup? Deploying a complete copy of the
SQLite database to all containers, is in essence doing the same thing.

4) How does this solve the problem of "major incidents were happening all the
time"? Is reading from a RDS (or similar) database really that fragile?

~~~
abetlen
Late reply but you might find it useful to check out this post which is much
more detailed [https://segment.com/blog/separating-our-data-and-control-
pla...](https://segment.com/blog/separating-our-data-and-control-planes-with-
ctlstore/)

I'm also left with some questions however. If the issue is the high read
latency with a centralised settings database, why not deploy read replicas?

------
pcdoodle
I agree with the article, I have a multiprocess app that works great this way
under Windows and Linux. It's nice having less moving parts for my
application.

------
teh_klev
Just a wee grammatical nitpick about the article title if the original author
is reading:

Sharing _an_ SQLite database -> Sharing _a_ SQLite database

~~~
nzmsv
Depends on whether you pronounce it see-kew-lite or ess-kew-lite :)

~~~
teh_klev
I think when you write "SQL", regardless of pronunciation, it should be "a".

~~~
maximente
no, the person you're replying to is correct.

the rule is about the sound of what follows, not whether or not it's a
consonant/vowel:

\- an SSD if you pronounce it ess-ess-dee

\- a universal constraint - vowel but a is correct here due to sound

\- an SQL database - again, pronunciation dependent

