These days, we don't use this any more. First, because we now use primarily original Boca printers and are allowed to use the official drivers, and second, because we do 99% of printing from Android devices, where we also handle the protocol conversion ourselves, but it's a lot simpler without CUPS. Still, was a fun ride doing this back then!
(Author here) Interesting! How do you differentiate between a bot and a screenreader user? Both won't move their mouse, scroll, etc but only send a single click event
(Author here) Anything else than first-come-first-served requires strong identity to avoid people trying to get better chances with many entries into the pool, thus falling into the "sacrificing privacy" category
(Author here) Yes, every kind of lottery/raffle is a possible solution but only with strong identity verification to avoid double-entry and hence only with sacrificing privacy, as mentioned in the article.
Our CI rans our test suite against all of SQLite, MySQL and PostgreSQL which worked well enough that I can only remember one or maximum two bugs caused by this, but yes, wise words.
Sure, the main reason for this is that nearly all of our tests touch the database and operate on a comparatively high level, we have way more things in a fuzzy category between functional and integration tests than actual unit tests. This is of course a flaw in our test writing, but it's what we have right now ;)
> Also it's unclear from the article but why would the followers be so out of sync? Is there a really bad network? Especially if they set quorum writes on the master then at least 1 follower should always be up to date.
Yeah, I should have gone into more detail there. I'm talking about cases like after an outage when there is a lot to catch up with, or worse, if there are conflicting timelines (e.g. after a power outage) and synchronization stops working completely -- the broken follower will still answer queries and I've not yet found a simple way to monitor this condition.
It certainly is a future perspective for us, moving to all-postgres, but forcing every installation of pretix (an open source application) to go through this migration is not something we'll do overnight ;)
That's weird indeed (although I don't see any connections to a http: URL in the dev console). If someone else reports a similar problem, I'll just remove piwik alltogether.
We haven't in depth, as they only advertise with their sharding and distributed query features etc and less with their HA features (if that is even in Citus Community).
Sharding data is something we won't do before we absolutely need it, since disk capacity is not at all our constraint right now and our scaling problem isn't that its hard to serve many tenants at once, but we may need to be able to serve one tenant with very high concurrency the minute their tickets go on sale (which would only affect one shard on a usual sharding setup).
Are you using Citus for HA? Would love to hear your thoughts!
However, having SQLite at hand for local development/testing makes things easier.
In my experience, real-world concurrency issues (that you are talking about) are always hard to find in manual/automated testing, or do you have a good strategy of trying that?
I may add that our development setup has no external service dependencies, redis is optional as well. Of course, we wouldn't recommend that in production, but we're kinda proud that it's possible.