Where Forms, Results and Cache Live

Where Forms, Results and Cache Live An architecture diagram generated by Archify. Forms & versions · SurveyJS JSON · locks · Architecture component · Plone content Forms & versions SurveyJS JSON · locks Plone content Submissions · poll_id · seq_no · site_id · Architecture component · per survey Submissions poll_id · seq_no · site_id per survey Tokens & monitoring · auth · embed · replay state · Architecture component · fail closed Tokens & monitoring auth · embed · replay state fail closed ZODB Data.fs · objects + result annotations · Architecture component · default ZODB Data.fs objects + result annotations default RDBMS tables · PostgreSQL · MySQL · SQLite · Architecture component · site_id indexed RDBMS tables PostgreSQL · MySQL · SQLite site_id indexed diskcache files · var/surveyjs-cache/{auth,embed} · Architecture component · single host diskcache files var/surveyjs-cache/{auth,embed} single host KV tables · dedicated PostgreSQL/MySQL URI · Architecture component · multi-host KV tables dedicated PostgreSQL/MySQL URI multi-host form versions annotations SQLModel rows default multi-host Legend Database Security

Forms are never a backend choice

  • • Form JSON and every version live in Plone content
  • • Restore and lock act on versions, not submissions
  • • No storage setting changes this

One backend for all results

  • • Switching ZODB ↔ RDBMS does not migrate existing results
  • • RDBMS rows carry site_id for multi-site setups
  • • Back up Data.fs and the database separately

Cache and tokens: separate switch

  • • diskcache files below var/surveyjs-cache by default
  • • Several hosts need a dedicated KV database URI
  • • An unreadable KV store rejects submissions