Session Management: B2C vs B2B Customer Facing Applications

As I was thinking about a good topic to write about this week, I couldn’t help but reflect on the subject of user session management. It is a critical topic that plays a pivotal role in shaping user experiences on customer-facing websites. Since being part of both B2C and B2B applications, I have noticed how different approaches to session management can either enhance or hinder user engagement.

In B2C applications, we have used a browser-level cookie with a 30-minute timeout, while the B2B applications employ server pinging every few minutes. Both approaches have their merits and challenges.

When designing a session management system, these are the architecture abilities considered:

Scalability: Our solution must handle varying user loads efficiently.

Security: Protecting user data and preventing unauthorized access.

User Experience: The system should balance security with ease of use. 

Flexibility: How flexible does the session management solution cater to different timeouts?

Performance: We must minimize the impact on server resources and network traffic.

Compliance: Our implementation should adhere to relevant data protection regulations.

Based on these considerations, our ideal implementation was 

For B2C

Since the number of users accessing the application is very high and requires high concurrency, there was a requirement for better user experience and performance. Hence, using secure HTTP-only cookies for session tokens was more suited. 

Also, since the application had several public pages, security was achieved by storing limited data in cookies and ensuring all secured information was on the server side. 

A distributed session could have been achieved, as there was a Redis cache layer. However, we wanted to keep the session stateless, and using a sticky session was available, and scalability was not an issue.

For B2B

Since concurrency was not an issue, server-side session management with client-side pinging periodically was a more apt solution. It did not hamper user experience SLAs and was more secure. 

Also, different b2b functionalities required different session timeouts. Keeping the logic on the server side made it more flexible and more controlled in terms of monitoring.

In conclusion, this is a good topic to revisit continuously, considering how the application security landscape is evolving, and so will our session management approach.  

In search of a cost effective strategy for modernizing a monolithic - Part 2

As I delved deeper into the discussions over the last few weeks, the challenges became a lot clearer and increasingly apparent. The tightly coupled modules and the massive Oracle database continued to be the focal points of our discussions. With only one developer possessing limited knowledge of the application, we found ourselves navigating through issues such as getting time from the developer, unknown assumptions, and several undocumented dependencies.

The initial domain identification process is still ongoing and getting time-consuming. Engaging with stakeholders and domain experts is not as planned as there are none :-(. Also discovered that what appeared to be distinct domains often had hidden interdependencies, further complicating our decomposition strategy.

The budget constraints also loom large as we progress. Every potential solution had to be weighed against its cost implications, forcing us to think creatively about resource allocation. The initial plan of migrating to the cloud is now squashed. 

One promising approach that I think could be a good fit is the strangler fig pattern. This strategy will hopefully allow for incremental modernization by gradually replacing specific functionalities of the monolith with microservices using the same technology. We identified a few non-critical modules that could serve as our initial targets to not risk core business operations.

As we move forward, the next crucial step is to create a business capability matrix and a detailed modernization roadmap. This roadmap will prioritize modules for decomposition based on their business value, technical complexity, and potential for immediate impact. 

The next steps seem to be a long process, but I am getting much more optimistic than before. Hopefully, the next time I write I will have the approach and roadmap finalized. 

To be continued...