Blog
add tag
Jack Douglas
### Will it scale?

[![](https://imgs.xkcd.com/comics/datacenter_scale.png)](https://xkcd.com/1737)

Right now, you could fit the TopAnswers server on your mobile phone with room to spare, but perhaps one day that won't be the case. It would be nice if everything doesn't grind to a halt on that day.

So we have to think about how we will scale, based on reasonable worst-case[^1] hand-wavy back of the envelope calculations.

Let's say we decide we want to keep on going even if we become as busy as Stack Overflow. How do we even begin to plan for that? Some would say we need to [use a particular language](https://forum.codidact.org/t/should-we-join-forces-with-topanswers/330/2?u=jackdouglas):

> I’m pretty confident in saying that PHP wont scale to the levels we are looking for, so I think we should continue our efforts on the asp.net core project.

[or](https://topanswers.xyz/transcript?room=4&id=7417#c7417) [database](https://topanswers.xyz/transcript?room=4&id=7423#c7423) (possibly in jest ;)):

> but will it scale

> It's on PostgreSQL so no

Of course those choices matter in their own ways, but we've been thinking about another particular angle, which is mostly independent[^2] of the technology choices we make: ***database state changes***, a.k.a. 'writes'. An important fact of any 'library of knowledge' that is seeing actual use, is that there will be a *lot more* reads than writes. That asymmetry needs to be considered — if we ignore it, all the people who make the content great will suddenly start suffering at the expense of the many more who are benefitting from that great content.

So, although it is early days, we have started to plan for this. We've just released a major update splitting TopAnswers into two. From now on there is topanswers.xyz (which everyone will know about and use) and post.topanswers.xyz (which no-one will know about and will only be used by the topanswers source code itself). The important distinction is that every operation that *does not change the database* will use topanswers.xyz and an HTTP GET, and every operation that *changes the database* will use post.topanswers.xyz and an HTTP POST.

We are telling you this now because:

1. we probably broke some things with the update (please let us know about any regressions).
2. you might be interested :)

When necessary, we will use the replication features of postgres to offload the [vast majority](https://stackexchange.com/sites#questionsperday) of activity off the master server (which will continue to handle writes). The url change makes this easy, and with some sort of DNS load balancing on the main topanswers.xyz url, we can take it a step further and have as many read-only replicas  as we need including, perhaps, one geographically near *you*.

So, we made a big change, it was a bit more difficult than we thought (forgot about CORS, had various issues with cookies etc), but hopefully you didn't notice. Now we'll get back to making some changes you've actually asked for!


[^1]: Or 'best-case' depending on how you look at it!
[^2]: Given that we really don't want to think about any multi-master replication technology unless we absolutely have to. And we probably don't.

Enter question or answer id or url (and optionally further answer ids/urls from the same question) from

Separate each id/url with a space. No need to list your own answers; they will be imported automatically.