2 PM Deployment, 3 PM Launch, and an Outage

After developing the SSG Club sign-up process, right after finishing the 2:30 deployment and just before the 3:00 launch, the sign-up button started failing randomly in the production environment.

The SSGPAY password input screen would sometimes appear normally, but then jump to an error page, and the results were inconsistent even without refreshing. It couldn't be reproduced locally or on the internal test server, and the problem point was the transition from the Gate page to the Register page.

The flow was as follows.

• On the front sign-up screen, the user's SSGPAY information is sent via POST
• Move to the register page via redirect
• Pass data using FlashAttribute
• On the Register page, receive it with @ModelAttribute and move to the payment registration screen

Initially, the intent was to avoid the resubmission warning on screen refresh and to prevent personal information from being exposed via query parameters. However, since FlashAttribute internally uses the session, problems arose in an environment configured with multiple WAS instances, as in production.

When POST /gate is handled by server A, and the redirected GET /register goes to server B, the FlashAttribute stored in the session disappears. As a result, some requests succeeded while others ended in errors, which looked like random failures in production.

The bigger problem was that this screen wasn't actually a page where users stayed long, but a bridge page where the form was submitted immediately upon entry and moved to the next step. In other words, the redirect, FlashAttribute, and session dependency itself were unnecessary in the design.

After the fix, the structure became much simpler.

• Call the Gate page with POST
• Render the screen immediately
• Auto-submit to the next step right upon entering the page

Now there's no redirect, no FlashAttribute, and no session dependency. Thanks to this, the structure became simpler and safer in the production environment.

In the end, the lesson learned is clear. A structure that looks clean and a structure that is safe in production can be different, and if a screen is one that users pass through only briefly, it's better not to assign it excessive meaning.