MyChatLab

Skipping a lesson was taking two to four minutes in production. From the application code there was nothing obviously wrong, and the operation was not doing an unreasonable amount of work. Reports of slow page loads had been accumulating for a while without a cause.

I stopped reading the code and ran the same script on two servers. From the Indonesian backend it took two to four minutes. From an Australian server it took under a minute. The application path was the same in both runs. So the comparison pointed to the network path to the RDS instance in Australia, with the latency cost paid per query, not once per request.

A vague performance complaint became a specific, located cause: cross-region latency between the application server and the database, amplified by query count. That moved the fix from optimizing the lesson-skip code to reducing round trips and reconsidering where the two halves run. I reported the two-server comparison on the project channel so the hosting decision remained with the people who could make it.

Three providers meant three webhook shapes and three notions of what a completed payment is, all landing in one user_subscriptions record. Status had grown into a set of strings covering trial, monthly, and one-off purchases per provider. A new signup was writing plain "Paid" where it should have written the more specific monthly status, so downstream checks read the wrong thing.

I worked through the lifecycle end to end: separate statuses for one-off Stripe and one-off Midtrans payments, an aggregate filter for every paying user, trial and expired filters for the admin list, a computed remaining-days field that goes negative once expiry has passed, coupon codes recorded against the payment, and cancellation from the parent record. Children inherit subscription state from whichever parent or teacher owns them, so a class does not need per-child billing.

Administrators could filter paying, trial, and expired accounts from one subscription model, while children inherited access from the parent or teacher who owned the billing relationship. To confirm the signup fix I ran a real checkout through to completion, then read the user_subscriptions row it produced. The defect was in what got written, so the status the interface displayed would not have told me anything. When duplicated email data broke payment lookups after an address change, I traced the drift to the subscriptions table and made profile updates propagate to it. Whether a parent could cancel was still decided by checking if the subscription status contained the word "paid", a workaround the existing status model left in place.

The reports and the in-app statistics disagreed consistently, and not by a rounding error. Neither was throwing an error, and both were reading the same database.

I traced both queries for each disputed number. Login count: the reports counted login records and session records; the stats page counted only login records. Word vault count: the reports counted two categories of completed task; the app counted one. Completed and remaining lessons disagreed for the same reason. Neither query had a defect; each one counted a different set of records under the same label.

I documented the definition behind each metric and reported the finding in the project channel. Comparing the underlying record categories showed that the defect was definition drift and not a broken query. The assignment ended before anyone reconciled those queries, so what came out of this was a diagnosis on record and not a shipped fix.