I have a very large monolithic legacy application that I am tasked with breaking into many context-bounded applications on a different architecture. My management is pushing for the old and new applications to work in tandem until all of the legacy functionality has been migrated to the current architecture.

Unfortunately, as is the case with many monolithic applications, this one maintains a very large set of state data for each user interaction and it must be maintained as the user progresses through the functionality.

My question is what are some ways that I can satisfy a hybrid legacy/non-legacy architecture responsibly so that in the future state all new individual applications are hopelessly dependent on this shared state model?

My initial thought is to write the state data to a cache of some sort that is accessible to both the legacy application and the new applications so that they may work in harmony until the new applications have the infrastructure necessary to operate independently. I'm very skeptical about this approach so I'd love some feedback or new ways of looking at the problem.

Edit: Per comments, the cache data is comprised of ~170 attributed about the user and account, so it is not super large. I can add more specifics if necessary.

To detail my ideas around caching, we are an AWS shop and I was considering using dynamo db as the cache and setting a TTL for each cache entry as the data will be useless after the user's interaction. I was thinking of having every application (whether in the monolith or a new app) write its state to the cache upon completion or when sending the user to another application. When the user hits a new application the state will be retrieved for use and updated when appropriate.

I believe this could be a good solution to the problem because it will allow the user's interaction to easily traverse between functionality in new and old applications. The risk is that there will be dependency on the old system and it may require substantial efforts to wean new apps off of the reliance on the cache in the future.

  • 2
    Your question is written in an extremely broad and abstract manner. I think to get sensible answers, giving some more concrete examples would help. For example, what does "very large set of state data for each user interaction" actually mean? – Doc Brown Jan 16 '19 at 21:37
  • 1
    It would be good to know things like how long that state will stick around, too. "As long as an HTTP Session" and "As long as the applications and all of it's descendants are in use" call for very different solutions. – aerohammer Jan 16 '19 at 23:38
  • @aerohammer the state data would be needed for the duration of the user's interaction and then could be deleted, to a TTL would be maybe an hour or two at most. – Will Evers Jan 17 '19 at 14:28
  • @DocBrown The state data is ~170 attributes about the user's account, so I guess it is not 'very large'. I can provide more specific details as needed. – Will Evers Jan 17 '19 at 14:28
  • 2
    @WillEvers: please don't let others search through comments to get relevant information, better use the "edit" button and improve your question text above. Moreover, can you give a representative example of what you have in mind with this state cache and how it could help to solve your problem? – Doc Brown Jan 17 '19 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.