Saboteur

Так и называется. Не нужно придумывать замену слову платформа - у всего есть своя платформа.

Например у 1С бухгалтерии - платформа 1С
У продукта 1С платформой может быть например windows (вроде под Линукс он еще не выходил)
У ОС Windows платформой может быть например архитектура x86

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

В некоторых случаях, можно еще указывать дополнительную базу, если продукт зависит от двух технологий, например 1С на базе файлов, или на базе SQL

Нет, это очень плохая структура работы с БД.
1. Если оба компьютера с программами в локалке, зачем для хранения файла выделять третий компьютер? Храните его на одном из компьютеров с программой.

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

А почему масштабируемость не выдерживает?
В проектах типа Lineage2 (онлайн до 5000, зарегистрированных аккаунтов до 15000) - это не проблема.

КАЖДЫЙ предмет - это строка в таблице items, с указанием владельца.

Поля примерно такие:
item_id, owner_id, item_type, param1, param2, param3
item_id - уникальный номер предмета
owner_id - ID владельца, можно добавить поле для координат и времени хранения для тех предметов, которые лежат на земле. Периодически их можно удалять, а те, у которых время хранения 0 не удалять.
item_type - ID типа предмета, в отдельной таблице храните все предметы и их неизменяемые параметры (вес, материал, название, описание, ограничения по расам, по куда одевать, все такое)
param1...param10 - изменяемые параметры предмета (заточки, цвет, эффекты, состояние поломки)
Для предметов типа деньги, монеты, бутылки - можно сделать столбец с количеством, для остальных предметов это всегда 1.

Положение предмета (типа одет, или в рюкзаке), можно делать или в этой же таблице, или в таблице владельца.

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

Любая нормальная база сама занимается грамотным кешированием в памяти, и двойное-тройное кеширование не нужно. Вы можете просто загружать объекты в память и обращаться к ним, а не к базе. Но если вы их меняете, то нужно регулярно сохранять. База это делает самостоятельно, поэтому нет смысла делать велосипед.
Что-либо тюнить имеет смысл, если у вас настолько высоконагруженный проект, что стандартные средства не решают проблему.

"1) Добавить транзакцию - всего несколько строк кода.
2) Как раз таки хотелось бы услышать, какие кейсы проблем здесь возможны"

Написать несколько строк кода - время разработчиков и деньги заказчика."
Протестировать несколько строк кода - время тестировщиков и деньги заказчика.
Добиться создания новой таски, которую оплатит заказчик - время менеджеров и деньги заказчика

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

Искать ответ на тостере, где не знают ни про ваш проект, ни условий работы, ни того, насколько легко добавить подобную задачу в спринт - вряд ли вы получите правильный ответ, есть даже вероятность что вы получите несколько разных ответов, но за правильный примете только тот, который лично вам по душе, а не тот, который более адекватный.

json был придумен не для хранения данных, это формат для того, чтобы данные упаковать, передать одним куском, с другой стороны распаковать с сохранением структуры.

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

IMHO ваша нагрузка вообще невелика. У меня на mysql живут проекты с несколькими миллионами добавлений в сутки, и я не считаю, что это едва середнячок.

MySQL все еще считается более популярным и в случае чего, проще найти для него ответы. Для вашего проекта я бы порекомендовал его.

Любой запрос займет больше секунды на 386sx

Чтобы понять нагрузку, нужно понять мощность сервера. Вместо теоретических вопросов, сделайте замеры.
Для этого существуют
1) нагрузочные тесты
2) архитекторы, которые понимают как запрос работает внутри, и по внешнему виду запроса могут предположить где будет основная нагрузк.

Просто проведите тесты, запустив 1, 10, 100, 1000 запросов, замерив время.

Реальные проекты, особенно мелкие - часто на виртуалках.

Выделять каждому ученику реальный компьютер под базу данных - дорого, а учитывая, что для обучения нужна СЛОЖНАЯ база из 2.5 таблиц и 10 строк в каждой, то на одном компе можно целый класс виртуалок поднять для каждого, дешево и сердито.

P.S. Практически весь хостинг, на котором сейчас крутятся сайты - это ВСЕ виртуалки.
P.P.S. Весь бизнес по возможности также виртуализируют, если есть возможность. Исключения - высоконагруженные машины, и то...
Виртуализация позволяет упростить процесс миграции, резервного копирования и т.д.