Waste less time on Facebook — follow Brilliant.

Brilliant’s Server Infrastructure (Professional Programming Series Micro-Post)

While thinking about topics for the Professional Programming Series, we realized people might find our server diagram interesting. I think it is worth posting because even though it is mostly industry standard, lots of the diagrams that you'll find on the internet are a bit more abstract and simply describe how things connect in a hypothetical situation. Instead, this diagram accurately represents how things work under the hood at Brilliant.

Click or tap for full size server diagram.

Feel free to ask questions about the server diagram, and I’ll try to answer as many as I can.

Note by Sam Solomon
1 year, 8 months ago

No vote yet
1 vote


Sort by:

Top Newest

Wait, why wouldn't you store the user media on the servers? I mean doesn't the data go through them when the user's device requests the data? Btw, nice job Nolan H · 1 year, 8 months ago

Log in to reply

@Nolan H Hi Nolan, great question!

For a while we did store user media on our application server, however, you may note that I used the singular "server".

Several benefits of using a 3rd party service for hosting files are:

  1. You don't have to worry about running out of disk space.
  2. You don't have to worry about semi-arbitrary OS restrictions (We once ran into an issue where we reached the maximum amount of directories that could exist in another directory).
  3. Most importantly, once you have more than one server processing requests for the same content, you either have to sync the files between all of your app servers whenever someone uploads something, or you have to make your own standalone server for hosting user media and set up the ability to pass files from all of the app servers to the file server when someone uploads them (which, at that point, why not use a service like Amazon S3 or Rackspace Cloud Files)

Also, if you look a little closer, you'll notice that "read only" arrows flow from the user browser through the Content Delivery Network (CDN) to the user media service. The typical way in which user media is used is:

  1. A user submits a form that includes a file.
  2. Our server processes the file and if validation passes, uploads the file to the file storage service.
  3. The server saves a new object in the database that includes the path to the image.
  4. When someone views a page that needs to display that object, we use an html img tag to reference the file on the 3rd party service (which is how most images are displayed anyways, even if they are hosted on the same server).
  5. Your browser sees the img tag and requests and downloads the file from the 3rd party service (skipping the app servers).
Sam Solomon Staff · 1 year, 8 months ago

Log in to reply

@Sam Solomon Ohhhhhh, ok. Once again, very cool. Nolan H · 1 year, 8 months ago

Log in to reply

I am just curious, how physically distributed are the app/task servers ? I mean, do you have separate dedicated servers for different continents (since the clients are from all over the world), or you have a centralized design ? Abhishek Sinha · 1 year, 8 months ago

Log in to reply

@Abhishek Sinha Unfortunately for now (though fortunately for our sanity) our servers are all centrally located. It is definitely something that keeps coming up, but it's a really big task to figure out how to split everything up. This is especially true because any type of distribution would likely require changes to how Brilliant works in order to make up for not having quick read/write access to all of the databases.

That being said, we do spend a lot of time figuring out how make the site faster.

We always try to reduce...

  • the number and size of files that need to be loaded
  • the amount of sequential round trips (redirects for instance, are relatively fast if you're close to the server, but can be very slow due to the redirect response and the resulting request needing to circle the globe)
  • client rendering time (you may notice that most math is actually rendered on the server side and only rarely will our JavaScript \( \LaTeX\) renderer have to step in to render math after the page loads (this is what the latex renderer server in the "Services" box in the lower right hand corner is doing)).
Sam Solomon Staff · 1 year, 8 months ago

Log in to reply

How do you manage Database write operation , So do you perform write operations into a DB , And use other DB for all read operation.

Isn't a master master architecture is more suited ? Vishal Vasudeva · 1 year, 8 months ago

Log in to reply

@Vishal Vasudeva We perform most write and read operations on the main database and perform some heavy read operations on the other.

Master-master architecture is good for some uses, but for us, the downsides aren't worth it at this point. The main things that we rely on that would be hard or impossible to get and have be efficient in a master-master setup are database transactions and a guarantee that once we store something in the database, it's immediately available for retrieval and will stay available (unless we explicitly delete it).

One of the main benefits of master-master architecture is having a quick failover which is possible to mostly accomplish with our setup by promoting the follower to be the master if the master goes down.

The other main benefit of master-master architectures is they can be used to distribute master-nodes around the globe so that you can have app servers closer to the browser, but distributing the database like that causes all sorts of synchronization problems unless you have a very simple site where the write operations are much more limited/orderly than we have (see this comment for a bit more info on why we don't yet distribute our servers). Sam Solomon Staff · 1 year, 8 months ago

Log in to reply


Problem Loading...

Note Loading...

Set Loading...