> multi-tenant-safe cache keys

> on a server-rendered app

> byte-for-byte identical (classic)

> gets a cache-speed response

> cached-file-extensions list

Honestly, this is terrible. I had to add a "use simple words only, don't hyphenate unnecessarily" warning to my Claude config. After a full day of work, having to read these Claudisms all the time make a noticeable difference on how tired you get. It gets even worse when Claude starts to make up its own vocabulary.

I surely missed a valid API token today.

Seems great on paper, but quickly turns into a nightmare. Magic is great to get you up to speed, but as soon as you find yourself having to bend the magic, good luck.

I review this kind of AI-generated Elixir code on a daily basis. And it makes me want to go back to ~2022, when code in pull requests actually made sense.

Apologies for the rant, this is just a burnt out developer tired of reviewing this kind of code.

PS: companies should definitely highlight "No low-quality AI code" in job listings as a valid perk.

Mostly as a fun experiment, but also from the realization that every place I worked at in the past (small/medium-sized B2B startups) would greatly benefit from such architecture.

Yes, there are massive trade-offs to this approach, and the concerns raised in the comment section are valid. This doesn't mean the database-per-tenant is never worth it. There's a sweet spot for it, and if it fits your business/application, I personally would consider it a technical advantage over competitors.

My goal with FeebDB is to eliminate or reduce the common pain points of database-per-tenant, including:

- ensure there is a single writer per database.

- improved connection management across all tenants (e.g. only keep open at most 1000 DB connections, similar to an LRU cache).

- on-demand migration (all shards are migrated on application startup, but if a shard that hasn't migrated yet receives a request, it will first perform the migration and then serve the request),

- on-demand backups and replication (e.g. the library knows which shards were updated in the last X minutes, so it can trigger Litestream or similar on demand).

- support for enumeration of databases (performing map/reduce/filter operations across multiple DBs)

- support for clustered deployment with "pinned" tenants (for now I'm assuming the IOPS of a single beefy server should be enough for all use cases, but once that's no longer sufficient you can have "shards of shards")

[0] - https://github.com/renatomassaro/FeebDB/

How can this ever be acceptable?

Demo: https://demo.ryot.io/_s/acl_vUMPnPirkHlT

Code: https://github.com/IgnisDa/ryot

(PS: they opted to go in a direction where it also includes some media-related features -- like tracking movies or books you've seen/read -- but this can be disabled).

These breaks were taken at a "natural" time, when you felt one was needed. By definition, an interruption is a "break" when you don't want one.

I actually have two projects that use this approach, FeebDB (which is the library I wrote to manage a "one SQLite database per client" approach) and HackerExperience (a game under development that uses FeebDB).

The overall idea is simple:

1. Before tests start running, create a prop of each database.

2. The prop contains the "starting database" for each test. It may contain seed data (optional).

3. For each test, copy the prop and assign it a unique shard identifier (say, cp /props/user.db /test_data/user/874125.db).

4. The test knows the `shard_id` and can do whatever it wants with it; no one else will bother it.

5. Once ExUnit is finished, delete all shards.

Both projects follow a similar approach (I wrote it first in FeebDB and copied into HackerExperience, which has some sections commented out -- I need to clean up this part of the codebase).

For both projects, you will find steps 1/5 in `test/support/db.ex`, step 2 in `test/support/db/prop.ex` and steps 3/4 in `test/support/case/db.ex`.

- FeebDB: https://github.com/renatomassaro/FeebDB/

- HackerExperience: https://github.com/HackerExperience/HackerExperience/

Email is in profile in case you have follow up questions/comments :)

This kind of setup makes the usual Ecto Sandbox approach feel slow, but I do agree that the way Elixir approaches this is great!

Comments URL: https://news.ycombinator.com/item?id=42354054

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=42244851

Points: 118

# Comments: 113

Comments URL: https://news.ycombinator.com/item?id=42017312

Points: 40

# Comments: 0

It will hurt even more.

The recommended way is to set up a witness server. Yet another thing to manage in a properly designed Postgres cluster. Certainly not an easy/trivial thing to do, ops-wise.

From [0]:

> By creating a witness server in the same location (data centre) as the primary, if the primary becomes unavailable it's possible for the standby to decide whether it can promote itself without risking a "split brain" scenario: if it can't see either the witness or the primary server, it's likely there's a network-level interruption and it should not promote itself. If it can see the witness but not the primary, this proves there is no network interruption and the primary itself is unavailable, and it can therefore promote itself (and ideally take action to fence the former primary).

An interesting acronym you'll hear is STONITH (in order to fence the former primary).

[0] - https://www.repmgr.org/docs/current/repmgrd-witness-server.h...