System-NS from the inside

After the publication of the last article , in which there was information about how and why we invented System-NS and what this service is, questions about our " internal kitchen " began to pour in us.

Just want to say that we are not a competitor of Cloudflare in any way, so I see no reason to tell you what is better. To date, our service is aimed only at managing domains. And unlike PDD Yandex, we provide Secondary and Dynamic DNS services.

Our task was to “use the maximum number of external modules” (in order to write less of our code). We spent a lot of time searching for suitable modules (with the necessary functionality and without bugs). In the process of this search, several of our young employees no longer firmly believe in the “immacuracy” of opensource projects. After screaming and massacre, they stopped at a bunch: ZF2 - Doctrine ODM - BjyAuthorize - ZfcUser.

A little more about the components.
Frontend:

• Zend Framework (ZF) 2. Since we used ZF for some projects earlier, when we started working on System-NS, we were extremely pleased with the release of ZF2, it turned out to be more convenient and more productive than its predecessor.
• Doctrine ODM. A module that allows you to convert mongoDB documents into php objects. In fact, this module was chosen by us to “see” what advantages it can give when working with mongoDB (usually we work through our class / wrapper). The module was redundant and not always convenient to use.
• MongoDB. Excellent document-oriented database, we use it for almost all of our projects (the only minus of the database is the lack of transactions, but with proper persistence you can implement them).
• BjyAuthorize. The mechanism for restricting access to certain parts of the site is based on the user's “roles”.
• ZfcUser. The module for managing users, contains ready (customizable) registration and authorization mechanisms. Perfectly compatible with Doctrine ODM and BjyAuthorize.
• Twitter Bootstrap. Very nice set of CSS templates, greatly facilitates the task with responsive design and layout in general.

Backend:

• A samopisny DNS server (C ++) is generally a separate story. I can not widely spread, since the project is closed by the NDA. The reason for writing it is only one - performance. In our implementation, one core per 2 GHz (capable of servicing up to 3-3.5 million requests per second), which corresponds to approximately 1.4 Gb dns traffic (average). The same technology, with the permission of the owner, was used in public service, but in a slightly reduced form. It has its own managed cache, but in general it depends on external data storage.
• Memcached - used as storage for the binary structure of domain zone records, instead of allocating memory in the dns daemon - for the sole purpose (see the next paragraph), although there were lengthy discussions on the fact that tcmalloc in dns itself would be faster, but decided not to load at all dns extra functionality
• A self-written daemon for replicating data across servers and saving snapshots to disk (C ++)

The service is physically located on five servers. On three of them (France, Ukraine, Russia) is the frontend. The remaining two servers (Norway, Czech Republic) are designed for replication. To balance the traffic, a fail-safe balancer from the company Clustertech AS (Norway) was used - which is located on the anycast segment.
')
Since the service is free - we still do not see the need to launch our anycast segment for it (although we have the opportunity), this is already from the category of expensive pleasure “for ourselves”, but it is possible that if there are a large number of applicants, we will launch it.

Thank you for your attention and interest in our service.