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 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. The substring-based cancellability check remained a compromise in the existing status model.

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.

The product sells across languages, and a transactional email is where a subscription becomes visible to the person paying for it. Translating the copy was straightforward; the header images, the placeholder values and the currency shown alongside them were what needed handling.

I built the email content on translatable text with placeholders, including trial expiry, so a message could carry account-specific values in any supported language. Header images switch per user language, and a trial user's subscription currency follows their selected language, not a platform default.

Account language became the shared input for localized email content and trial-subscription currency, instead of choosing those independently per message.