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.

1. 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.

2. 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.

3. A scheduled task in app A that aggregates data in a non-web process and uses an api in app B to save it.

4. Other

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.

Thanks

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.

1. 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.

2. 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.

3. 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?

I'm trying to find the best architecture for an application that shows a dashboard with aggregated stats that come from another one (e.g. number of sales in the last 12 months, current sales this month, a fairly complex score, performance of users over last 30 days, etc.)

There is a fair bit of business logic that lives in Application 1 but the aggregated data gets saved in Application 2 (dashboard).

What's the best way to create the aggregate data?

1. Pull data directly from Application 1 database and duplicate business logic for score calculation etc.
2. Push data from Application 1 to Application 2 somehow
3. Aggregate data in Application 1 on the fly and provide and api for Application 2
4. Other (probably)

Please suggest solutions,

Thanks.

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.

1. 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.

2. 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.

3. A scheduled task in app A that aggregates data in a non-web process and uses an api in app B to save it.

4. Other

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.

Thanks