(SLB) Schlumberger

The system had two sides: an editor used to create branching onboarding experiences, and an engine used to run those experiences for many users at the same time. My work was mainly backend and architecture. The interesting problem was making independently built components behave like one system when state was changing in real time.

It looked like a normal web application until you asked what happens when hundreds or thousands of people are inside the same experience and their state has to stay consistent. Where does the authoritative state live? Which events need to propagate immediately? What belongs in persistent storage and what belongs in live session state? What happens if two components have different assumptions about the same object? What should the engine know about the editor, and what should stay completely separate?

Those questions mattered more than any individual endpoint.

I spent a lot of time on component boundaries, class design, data flow, backend behavior, and how the editor and engine should communicate.

The stack was a React editor, a C# engine, .NET services, Azure, CosmosDB for what persists, Redis for live session state, and SignalR for real-time behavior. I also worked on speech parsing and tests on the paths where state moved across multiple parts of the system.

A large part of the architecture work was making sure one decision did not quietly create three different interpretations elsewhere.

Different people were building different components, and assumptions that seemed obvious inside one part of the system were not always shared. Integration got slower because some problems were mismatched mental models rather than code defects.

A few of us pushed for clearer requirements, earlier dependency checks, more direct communication, and better documentation of architectural decisions. A design is only useful if the people building it share the same understanding of it.