Which application backend should Theatora compose first?

[asopitech]

Theatora is being shaped around real backend compositions rather than an abstract catalogue of services.

Share one application whose backend would be a useful test case. A rough idea or an existing production system is equally welcome.

• What kind of application is it, and how large is its audience today?
• Which capabilities does it need: identity, relational data, objects, queues, realtime, compute, workflows, observability, or something else?
• Which providers and runtimes does it use now?
• How should the composition change from one laptop to production and distributed topology?
• Which persisted data must remain stable, and where would migration or rebinding be risky?

AlopexDB is one path we want to test explicitly: embedded → single-node → distributed while keeping one native data model. Comparisons with SQLite/PostgreSQL migrations, other databases, and counterexamples are especially valuable.

Concrete configurations, constraints, and failure modes will help us decide which capability contracts, provider interfaces, and lifecycle operations Theatora should define first.