Сергей

Веб больше и полнее. Веб это не только html/css, веб это еще различные сервисы с различным API.
В системном программировании вы будете больше привязаны к своему работодателю, нежели в веб.

С интеграцией с сервисами ABBY

Найдите знакомого ИПшника и от его имени начинайте обслуживание. Я правда не вкурсе про роспотребнадзор, но наверное если никто не отравится то и проблем с ним не будет (он о вас не узнает).

Тривиальная задача реализовать такое на Erlang.

Если программировать не умеешь, то как себя не назови разработчиком ты не будешь.

А никак. Роутер является сам по себе NAT а дальше может быть еще куча NAT, в том числе и провайдера.

Проиндексируют.

Поднять прокси. И пусть люди ходят только через неё. Все действия людей логировать, передаваемую информацию тоже. Обрубить возможность работать с флешек, дискет, дисков и т.п. загрузочных вещей.
Подписать со всеми согласение о неразглашении информации и т.п.

P.S. Не безопасник я.

Riak ? Правда там по моему без блокировок и транзакций, но всегда можно дописать функционал.

Я за. Ставь мне плюс.

Это они наняли пачку верстальщиков (20 штук), те им проект отверстали за "испытательные". А потом они со всеми попрощались с формулировкой "вы нам не подходите".

На Erlang конечно.

Развивайтесь в той области, где меньше всего людей (конкурентов). Ищите удаленную работу и не только в России.
Надувайте щеки. Начинайте с малого.

ответ на п3.
Конечно регистрация за рубежом, с нашим бюрократизмом и валютным контролем больше мороки.

Написание функций целесообразно при обработке больших объемов данных, когда передача их по сети будет идти дольше чем сама обработка.

Написание хранимок вещь великая, но:
1. их нельзя подвести под версионный контроль
2. Если вся логика будет на БД, то рано или поздно нужно будет апгрейдить сервер с БД. В свою очередь если мы используем БД как хранилище (без обработки), то у нас будет больше времени подготовится к очередной смене архитектуры системы, когда БД в очередной раз будет узким местом.
3. Лучше в системе определять различные подсистемы ответственные за определенные бизнес-задачи, так вот обработка бизнес-логики не есть прямая задача базы данных.

Еще как вариант, хранить текущую аггрегированную статистику за 10-20 мин в памяти, по необходимости скидывая это дело в базу. Т.о. вы можете получить аггрегированные данные в реальном времени.

Основная проблема в том, что пользователи таких систем хотят получить:
1. Данные в реальном времени (с минимальной задержкой)
2. Получить аггрегированные данные в различных разрезах (заранее определенных)
3. Строить доп разрезы на основе исторических данных (приходится обрабатывать колосальные объемы за предыдущие периоды)

Хостится в Китае ?

На С\С++ разрабатывают автомат, который читает входной поток исходного текста и генерирует абстрактное синтаксическое дерево исходного кода. Далее это проходит определенные преобразования, и на выходе будет программа для интерпретатора или программа в машинных кодах или программа для виртуальной машины (для отображения в частности HTML).

Разработка такого инструмента на C\C++ или на чем то еще не вызывает затруднений. Т.к. это все языки с полнотой по Тьюрингу. Т.е. все алгоритмы которые вы можете реализовать в рамках этих языков могут быть реализованы простейшей машиной Тьюринга.

Скорее всего нет. Осуществление предпринимательской деятельности без регистрации ИП.
Но ваши "денежные объемы" никому не нужны.