bogdan: Thanks for this info. I was under the impression the SystemID is used by OTRS only when deciding which emails to process from an assigned inbox via PostMaster

It is, but that would mean it wouldn't be able to process incoming emails from the other OTRS system, the system ID gets embedded in the full ticket "number", the system ID is primarily used to allow separate OTRS systems to send emails back and forth (assuming the system IDs are different) without screwing up other tickets already in your database.

bogdan: Let me just clarify what I mean. I assumed OTRS *requires* "sticky user sessions" (aka all http request/responses from a given user session need to pass through the same app server). This is required by web apps that hold user session data in memory or on disk between http request/responses. I assumed OTRS requires "sticky user sessions" because I saw a lot of generated files in /var subdirs.

Can I conclude OTRS actually stores *all* user session specific data in the database, between response/requests? My impression was that it stores just a list of sessions so that an admin can see them in the admin UI.

That is what I have always assumed, if you look in the sessions table in the DB in the session_value column you can see that there is all of the user's configuration in one big string.

bogdan: I'll explain what I meant. Many apps supporting heavy concurrent usage implement entity versioning. This means that when the app reads a document from the db (such as a ticket) it also reads its version. The user changes the entity in the web UI and when the user saves the change the app first checks the version of the entity to ensure it is still the same as when it was initially read. If the versions differ, the app either throws an error or does something more elegant to reconcile the differences. What's important is that in this way the app protects against silently losing changes. I was aiming to find if OTRS does entity versioning when I asked "Does last db write always win?" and I mainly asked because I saw many tables saving a change time for each row. The change time could be used for entity versioning.

OTRS isn't that "clever" and certainly doesn't do versioning. Many tables are updated when the data is added to a ticket as it's not stored in one big flat table.

bogdan: I think it's self obvious it's not practical to store attachments in the db when you obtain a db that's 90% attachments and 10% everything else. I would like to store this db on fast storage and it's hard to obtain budget for high capacity ssds when most of the data on them is dead weight. Backup management would become a pain, some queries would be heavily impacted and all db operations (moving to qa/dev envs, etc) would be unreasonably slowed down by such a large db. OTRS's official docs also acknowledge this practical matter.

Yep, but like I said there is nothing stopping you from doing it, but it does have it's drawbacks. Like David said if you are going to store this on disk then you will need to use a cluster filesystem, and I'm not entirely sure how this will work with multiple front end servers, hence why storing it in the DB (even given its "issues") would be the easier option as the frontend doesn't need to worry about being able to access the filesystem, it's all in the one place.

It might be worth contacting OTRS support directly to see if they do have load balanced implementations and whether they would share any of the implementation details (can't help but to ask), but if you are going to have such a large installation anyway then it may be worthwhile taking out official support should you run into any issues with the implementation, at least then you are guaranteed help on the end of a phone.

Steve