Kwok

I'm a senior engineer building apps in public. I document the engineering patterns that actually work. Follow me if you want: 👇 ⚙️ Better backend skills 🤖 Smarter AI powered development 🏗️ Scalable architecture habits 🚀 Guidance for busy developers who want to ship

7 benefits of canary releases for junior devs: 1. Smaller release bets 2. Faster feedback from real users 3. Earlier bug detection 4. Easier rollback decisions 5. Less pressure during deployment 6. Better habits around monitoring 7. A clearer sense of production ownership Small rollout first. Big rollout later.

Legacy code is not always the enemy. Sometimes it is just old code that still pays the bills. The real mistake is turning modernization into a heroic rewrite. That creates years of risk before users see value. Better architecture is patient. Small slice. Real traffic. Safe rollback. Then the next slice.

Config drift detection matters because: 1. It catches silent differences 2. It keeps staging aligned with production 3. It makes incidents easier to explain 4. It exposes manual fixes that were never cleaned up 5. It stops one server from becoming special 6. It turns guessing into checking Compare them regularly. Alert while the differences are still small.

You need better percentiles. Average latency tells you what usually happens. P99 tells you where users start waiting, refreshing, complaining, and sending screenshots. Averages are for reports. P99 is for product reality. 6 steps to improve P99: 1. Measure end to end 2. Split the request into timed sections 3. Look at distribution 4. Group by endpoint, tenant, region, device, cache hit 5. Remove the biggest tail source 6. Alert on P99 after deploys Do this before adding more servers.

@PaulGugAI Haha that's true, good one 😁

@kodemojo Less is more so more becomes less, as they say.

@neerajjj6785 Thank you, hope it's useful for you.

@kodemojo Nice share!

Flaky tests seem harmless at first. One red build. One rerun. One “probably nothing.” But the real cost is not the extra five minutes in CI. The real cost is what happens after enough false alarms. Engineers stop trusting the signal. And once that happens, the test suite becomes decoration with opinions. For software architects, flaky tests are not just a testing issue. They are a design smell. They often expose problems with time, state, data, boundaries, and ownership. The better question is not: "Can we rerun it?" It is: "What is this test trying to tell us?"

5/5 Pro tip: Before adding a log, ask: "Will this help me debug at 11 pm?" If not, add better fields. Your future self does not need a diary from your app. Your future self needs facts.

4/5 One rule I like: Log events, not diary entries. A diary entry says: "Something went wrong." An event says: "This happened, in this service, for this request, with this result." That is the difference between noise and evidence.

1/5 The teams that handle production well are usually not better at guessing. They are better at logging. That matters more than most developers think. Because when production breaks, the real question is not: "Who is the smartest person in the room?" It is: "Who can find the facts fastest?"

Threat modeling is not about being afraid. It is about asking the questions before production asks them for you. Who can reach this? What can they change? What can they read? What can they fake? What would we wish we had logged? That is part of good design.

A fragile consumer: - Receives an event - Does the work - Hopes it never receives that event again An idempotent consumer: - Receives an event - Checks whether it has already handled it - Produces the same result every time That tiny check prevents a lot of problems.

A circuit breaker is like a fire door. It does not prevent the fire. It limits how far the fire can spread. Services need the same kind of boundary. One dependency can fail. But that failure should not drag down the homepage, checkout, auth flow, and reporting screens with it.

Least privilege is easier to apply when you keep this in mind: 1. Permissions tend to expand over time 2. Temporary access often stays longer than intended 3. Roles almost never reduce themselves 4. Leaked tokens inherit all granted permissions 5. Cleanup requires deliberate action

Thread pools when they are healthy: - Work waits briefly - Workers stay busy - Downstream systems survive Thread pools when they are ignored: - Queues grow forever - Workers block each other - Timeouts appear somewhere else

Most developers only learn indexing after they hit a slow screen, a red dashboard, and a long Friday. You do not have to learn it that way. Understand the different index types now. Future You will write better queries and save a lot of time.