Scaling Bitbucket’s Database

"Bitbucket uses PostgreSQL with one primary read-write database and N read-only replicas."

I am architecting a project that is at a smaller scale but bears some resemblance, and I’ve already settled that I will be very careful about GET vs POST&#x2F;PUT semantics and route all traffic of the former only to the replicas and all of the latter through a connection pool to the primary. That, I expect, will hold me well into &gt;1% of their traffic.<p>I’m not sure if I’ve missed something with their LSN work or if this indicates that the GET semantics horse has already escaped their proverbial barn. Within the call-response of a single request, which they seem to be talking about, none of this should be necessary. Right?<p>However a cascade of narrowly-spaced follow-up requests could easily catch you in this trick. Lie. Whatever you wish to call it.

Bitbucket is a perfect case for sharding. You could have one DB of users, and N DBs of user data, with the first referencing the latter, and then distribute user data among the latter. You could do this straight up with PostgreSQL without any special server-side software. You could also have a PG server using FDW to act as a proxy for all the DBs a client needs to be talking to. There are many other options too.

Bitbucket (mostly via Atalassian) worked very hard to chase everyone off their platform in the vain hopes that the OSS community would start using Jira. Clearly they bet wrong, but unfortunately they aren&#x27;t going to get any users back for a very long time.

Does storing the LSNs in Redis and Elasticache create the same race condition they are trying to avoid or am I missing something?

Yea I&#x27;m not taking advice from a service that&#x27;s down once a week

Is it just me or does looking at write logs to determine read consistency just seem like a really bad way to do this vs a different load balancing strategy?

It&#x27;s amazing that Atlassian still exists.

Curious that they use LSN tracking vs making the replication synchronous. I would be curious to see the performance numbers and the reasoning behind the choice.

Oracle offers DML redirection for active dataguard setup where a write operation on the replica database is redirected to the primary database to allow applications that make infrequent writes to actively run on the Active Data Guard replica database. Also the write operation completes when the replica has seen the write from the primary thereby eliminating the race condition avoiding such complex reengineering

That&#x27;s really neat! I wonder, could you store the PostgreSQL log sequence numbers in a cookie to save the round-trip to Redis?

I found it interesting that their cloud version of bitbucket uses Django while their self-hosted stack is almost entirely Java.

Step 1: Remove Mercurial support.

&gt; we find a replica that is as up to date as the user&#x27;s saved LSN<p>The article doesn&#x27;t explain how they know the current LSN of each replica?

10ms to do a redis get? What am I missing here...

Still salty about them dropping mercurial support without providing any migration tools, and planning to just delete data without any archiving.