Сама же модель хранится в формате SQLLite. Diff легко получить.

Дифф не поможет. Его ещё обработать надо.

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

А это только экспертная оценка, Тут никакое средство не поможет. Увы...

Это сомнительный тезис, на мой взгляд.

Как минимум я могу выявить все связанных отношениями объекты модели, и сгенерировать описания 'дырок", которые нужно закрыть.

Можно поднимать каждый контейнер в отдельной vm, это дешево

Ещё есть правила верификации-валидации моделей, которые позволяют оценить влияние изменений на результат.

Сначала придется в модели определить как каждый элемент соотносится с X. Это можно, средства есть, например именованные значения. Но, это напоминает моделирование ради моделирования.

Можно подробнее, "моделирование ради моделирования", что вы имеете в виду?

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

На самом деле в visual paradigm процессы мерджа достаточно удобно сделаны. Не могу сказать, что прям полностью доволен инструментами управления ветками/тэгами, но в целом норм. Другого средства создания диаграмм, которые могут править несколько пользователей, не знаю. Правда сильно и не искал.

Подскажите, что есть для реализации http кэша? История простоя - кэшируем GET на /entity.*, удаляем кэш на POST/DELETE/PUT /entity . Я что-то понял, что сходу только varnish в голову приходит.

А чем уровень приложения не устраивает?

А как его сделать на распределенном приложение? Мне интересно именно готовое решение найти. Кэширование это же основа rest

Почему это "основа REST" ?

Ну точно его значимая часть :) кэш один из архитектурных элементов rest архитектуры

Я с научными определениями rest не знаком, но из практики - это не то кэширование, про которое вы пишете.  
Кэширование является частью rest в том смысле, что сервер должен сообщать клиентам что можно кэшировать (и на какой срок), а что нет.  Это совсем не значит, что сервер должен предоставлять клиентам какие-то готовые АПИ для кэширования объектов.  
На уровне серверного приложения можно (а иногда и нужно) использовать распределённые кэши, типа того же ignite, infinispan, hazelcast и т.п.  В них есть всё необходимое (кэширование, получение, инвалидация по критериям и т.п.)

.
3.4.4 Client-Cache-Stateless-Server (C$SS)

The client-cache-stateless-server style derives from the client-stateless-server and cache styles via the addition of cache components. A cache acts as a mediator between client and server in which the responses to prior requests can, if they are considered cacheable, be reused in response to later requests that are equivalent and likely to result in a response identical to that in the cache if the request were to be forwarded to the server. An example system that makes effective use of this style is Sun Microsystems' NFS [115].