Mautic: M3 Work group - App/Infra architecture

[npracht]

Description

This group is meant to define guidelines for the architecture of Mautic 3's app and infrastructure. These guidelines will be presented to the mautic community and completed with the given feedbacks.

Team

Leaders: @dcoutelle, @Gregy

Of course, this group is open to any contributor with a constructive opinion.

Topics

• Do we target master/slave, multi tenant (file ? database ?), etc. support?
• Cache management (build in cache, custom, etc...)?
• ORM (database support, target 2d lvl cache, with 100% ORM using, etc..)_

Pay attention to Issues met in 2.x

• SQL Concurrency
• Batches management

[wittwerch]

I would love to see Mautic 3 being event driven in a way that all actions trigger events that are processed by workers.
Getting all the cronjobs right, choosing the right intervall and monitor the output is super hard. Additionally it adds lag to the system, as I have to wait another minute till my segment is updated.
Ideally updating a lead would fire an event, which is immediately picked up by a worker that updates that segment. You wouldn't need to create cronjobs but just make sure that this daemon is running. That would also help to scale out, by putting these workers on different computing nodes.

Symfony provides all we need with the Messenger component (https://symfony.com/doc/current/components/messenger.html). I hope that's something you might consider, as we are talking about a major release :)

[npracht]

More and more we're Ajaxifying stats because it takes a lot of time to display them in the interface (bigger the instance is, longer it is).
We should imagine adding stats in cache.