I'd like to know what are common architectural pattern for the following problem.
Web application A has information on sales, users, responsiveness score, etc. Some of this information are computationally intensive and or have a complex business logic (e.g. responsiveness score).
I'm building a separate application (B) for internal admin tasks that modifies data in web application A and report on data from web application A.
For writing I'm planning to use a restful api. E.g. create a new entity, update entity, etc.
In application B I'd like to show some graphs and other aggregate data for the previous 12 months. I'm planning to store the aggregate data for each month in redis.
Some data should update more often, e.g every 10 minutes.
I can think of 3 ways of doing this.
A scheduled task in app B that connects to an api of app A that provides some aggregated data. Then app B stores it in Redis and use that to visualise pages. Cons: it makes complex calculation within a web request, requires lot's of work e.g. api server and client, storing, etc., pros: business logic still lives in app A.
A scheduled task in app A that aggregates data in an non-web process and stores it directly in Redis to be accessed by app B.
A scheduled task in app A that aggregates data in a non-web process and uses an api in app B to save it.
I'd like to know if there is a well known architectural solution to this type of problems and if not what are other pros/cons for the solution I've suggested?
