Employment work
Architecture evolution
Earlier product work at the same employer: event-driven integration, a monolith migration, and access control.
Context
Before the Staff role, I worked on several architecture changes inside Brain Station 23 product teams, spanning product integration, service extraction, and access control.
Problem
Teams needed to connect products without tight runtime coupling, separate a monolith into clearer services, and give multi-department users access that matched how the organization actually worked.
My role
I designed and implemented a serverless, event-driven integration using AWS Lambda, EventBridge, and API Gateway so a sister product could integrate with loose coupling. I led a migration from a monolith toward microservices. I implemented single sign-on with Auth0 and object-level access control across departments. I also delivered full-stack features across Django backends and Vue.js frontends.
Constraints
The sister product and internal topology are confidential. The public detail therefore focuses on the decision boundary, my contribution, and the resulting architectural change.
Reasoning
Synchronous calls between products are simple until one side’s outage becomes the other’s outage. An event-driven boundary costs more to operate and is worth it when the products should evolve on different schedules. A monolith split is the same kind of choice: extract a boundary when ownership and change-rate demand it, not because microservices are a default.
Outcome
The integration shipped with looser coupling between products. The migration improved service separation. SSO and object-level access control gave multi-department users a clearer authorization model.
Reflection
These projects are why I pair architecture advice with hands-on help. The most useful artifact is a decision the team can implement, operate, and revise as the system evolves.