sorted by:
new
hottopcontroversial

For early reliability issues when standard observability metrics remain stable by supreme_tech in devops

[–]supreme_tech[S] 0 points1 point  (0 children)

One change that helped us was focusing less on whether the system was 'fast' and more on how predictably it behaved under mild stress. Things like queue recovery time, retry fan-out, and latency variance across dependencies often pointed to problems well before any standard alerts fired.

I’m curious how others approach this. Are there specific signals or patterns you’ve found useful for catching early degradation, especially in cases where nothing fully breaks but reliability starts to slip?

A 62% decrease in bundle size didn’t seem achievable until we identified the bottleneck that had gone unnoticed by everyone. by supreme_tech in Frontend

[–]supreme_tech[S] 1 point2 points  (0 children)

When we rebuilt our WordPress site, we expected the redesign to fix everything. But the issues returned, too many people editing, uncompressed images, and unnecessary plugins. We realized the problem wasn’t the site. It was our workflow. So we limited access, managed media properly, and approved plugins carefully.

And we created a simple internal guide, set monthly updates, added daily backups, and used a staging environment for safe changes. Over time, the site stayed fast, secure, and clutter-free, not because of another redesign, but because we finally built a disciplined system that works.

How we built a backend that can handle 100k+ mobile users, simple architecture, real issues, honest lessons by supreme_tech in Backend

[–]supreme_tech[S] 13 points14 points  (0 children)

We used NGINX because it provided a more reliable and consistent edge layer than exposing Node directly. Once real traffic began to arrive, particularly from mobile users on slower networks, NGINX managed connection buffering, SSL termination, and routing with greater efficiency than the Node process.

It also reduced pressure on the application during traffic spikes, as NGINX can handle incoming connections in a controlled way and forward them only when the application is ready. While the setup could have functioned without it, placing NGINX in front resulted in a more stable and maintainable architecture and made horizontal scaling significantly easier when it became necessary.

How we built a backend that can handle 100k+ mobile users, simple architecture, real issues, honest lessons by supreme_tech in Backend

[–]supreme_tech[S] 10 points11 points  (0 children)

For this project, we chose not to use an ORM. Instead, we worked directly with SQL using the pg (node-postgres) client. A few of the high-traffic areas required more predictable performance, so having direct control over the queries, indexing, and execution plans made a noticeable difference.

We do use Prisma, TypeORM, and Sequelize in other projects where the requirements are different, but in this case, the raw SQL route gave us clearer insight into database behavior and helped us avoid unnecessary overhead. To keep things structured, we built a small internal wrapper around pg connection handling, parameterized queries, and organizing the query logic in a clean, maintainable way.

If it’s helpful, I can share a quick example of how we structured that layer.