The Architect’s Veto: Why "Just Building It" is Rarely Enough

Generic software development is often described as a game of execution. You get a requirement, you write the code, you pass the tests, and you deploy. In the era of high-speed delivery and AI-assisted coding, we have become remarkably good at the "building" part of the process.

But as the complexity of our systems grows – especially in high-stakes environments like gaming, fintech, or ad tech – the ability to build is no longer the bottleneck. The real bottleneck is the ability to verify.

Recently, I was leading a project for a major gaming platform. The client arrived with a very clear, very detailed solution. They had a plan, a timeline, and a vision for how their new anti-addiction session management should work. It was well-thought-out, fit their timeline, and seemed ready for implementation.

The easiest thing to do would have been to start coding right away. But at Appliscale, part of our responsibility is to look past the initial plan and ensure the outcome actually meets the goal.

The "Given" Solution: Problem with Reactive Architecture in Compliance Systems

The requirement was to enforce strict playtime limits for minors. The proposed design followed a familiar reactive model: a Session Service would issue stateless JWTs, while a Compliance Service tracked playtime via asynchronous events.

The plan was straightforward:

• Allow the user to log in.

• Emit an event.

• Have the Compliance Service track the time.

• When the limit is hit, send a "Revoke" signal to the client.

It was a "given" solution. It was logical and fit perfectly into the existing infrastructure. On paper, it was ready for implementation.

Finding the Flaw: How Stateless JWTs Can Become Exploits

In many organizations, the pressure to "just start building" is immense. A junior engineer would have started writing the event handlers. An AI tool would have generated the boilerplate in seconds. We would have "delivered" the feature on time.

But I realized that my responsibility wasn't to the plan – it was to the outcome.

I took a step back. I looked past the implementation details and looked at the system through an adversarial lens. I asked myself: If I were a player who didn't want my game to end, how would I beat this?

That was the moment the Recreation Loop became obvious. Because the Compliance Service only registered sessions after they were created, and because we couldn't rely on an untrusted client to obey a revocation signal, a user could simply log in again, get a fresh token, and substitute it. The "stateless" strength of the JWT was being turned into an infinite exploit.

I realized that if we followed the plan as given, we would be delivering a system that failed its primary regulatory goal.

The Consultant's Perspective: Moving to Proactive Eligibility Checks

Being an architect is often about knowing when to stop the train. It's about having the professional courage to look at a client’s ready-made plan and say: "This won't work."

But a consultant’s job doesn't end with finding a flaw; it continues with proposing a better path.

Instead of the reactive model, I suggested a fundamental shift: a Pre-Issuance Eligibility Check. We moved the policy boundary from the logout event to the login attempt itself. We proposed that the Authentication Service act as a gatekeeper, checking eligibility synchronously before signing any token.

This was a more complex path. It required careful management of service dependencies and a robust "Fail-Open" strategy to maintain system availability. But it was the right solution for the problem at hand.

Why at Appliscale We Emphasize a "True Consultant" Engineering Mindset?

At Appliscale, we emphasize being "True Consultants." To us, that means we aren't just order-takers. We don't implement a design just because it’s easier or because it fits a pre-existing plan. We take ownership of the architectural outcomes.

This story is a reminder of why that mindset matters. In an era where building code is faster than ever, the real value lies in the human capacity to verify the "Why" and ensure the architecture is sound.

The system we eventually built was successful and stood up to adversarial testing. But looking back, the most important work happened long before the first line of code was even written – when we took that second look at the "given" plan.

---

For a deeper dive into the technical details of the JWT recreation loop and the pre-issuance enforcement model, see our full technical case study: JWT Revocation at Scale: How to Enforce Playtime Limits for >100 mln Users.