blog

2026-06-19

Hello, world — starting this blog

I've been meaning to write more for a while. Not because I have anything particularly important to say, but because writing something down forces me to actually think it through instead of letting it float around in my head as a vague feeling.

So this is the first post. The bar is low. The plan is to write short things, often, about whatever I'm building or reading.

What I'll probably write about

• Backend systems — caching, queues, databases, weird bugs
• Side projects and what I learned shipping them
• Tools and tiny optimisations to my workflow
• Occasionally, things that have nothing to do with code

Write drunk, edit sober. — not actually Hemingway

If you're reading this — thanks. See you in the next one.

metawriting

2025-06-15

Predictive caching in backend systems

Most caching strategies are reactive: you wait for a request, miss the cache, hit the database, and store the result for next time. That works, but it pays the latency cost on the first request every time.

Predictive caching flips this around — you try to figure out what's likely to be requested next, and warm the cache before the request arrives.

A simple example

If a user just loaded page 1 of a paginated list, there's a good chance page 2 is coming next. So you fetch it in the background and put it in Redis with a short TTL.

async function getPage(userId, page) {
  const key = `list:${userId}:${page}`;
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const data = await db.fetchPage(userId, page);
  await redis.setex(key, 60, JSON.stringify(data));

  // warm the next page in the background
  prefetch(userId, page + 1);

  return data;
}

The trick is not overdoing it. Prefetch too aggressively and you're just burning database load on things nobody ever asks for.

backendcachingredis

2026-06-20

Logging in backend systems

Logging is a critical part of any backend system. It helps you understand what's happening, debug issues, and monitor performance.
in backend systems. It helps you understand what's happening, debug issues, and monitor performance. But it's easy to get wrong. Here are some thoughts on how to do it better.

1. Log at the right level. Use different log levels (debug, info, warning, error) appropriately. Don't log everything at the same level, or you'll end up with a noisy log that's hard to sift through.
2. Include context. Make sure your logs include enough context to be useful. This might include user IDs, request IDs, timestamps, and any relevant data that can help you understand the situation when you look back at the logs.
3. Don't log sensitive information. Be mindful of what you're logging. Avoid logging sensitive information like passwords, credit card numbers, or personally identifiable information. If you need to log something sensitive for debugging purposes, make sure to mask it or remove it before logging.
4. Use structured logging. Instead of logging plain text, consider using structured logging formats like JSON. This makes it easier to parse and analyze logs, especially when you're dealing with large volumes of log data.
5. Monitor your logs. Logging isn't just about writing to a file or a logging service. You also need to monitor your logs to catch issues early. Set up alerts for certain log patterns, and regularly review your logs to identify any potential problems or areas for improvement.

logging formats

There are several formats you can use for logging:

• Plain text: Simple and human-readable, but can be difficult to parse programmatically.
• JSON: Structured and easy to parse, making it ideal for automated log analysis.
• XML: Another structured format, but less commonly used than JSON for logging.

but mostly we use file based logging and critical logs with console. every logging method has a structured format to follow to undeerstand the logs better by using formatters and loggers. formatter also it contains handlers to handle the logs and send it to the right place. handlers where internal handlers are used to handle the logs and send it to the right place. handler can have many file asigned to it and each file can have different log level assigned to it. loggers

logger are used to organize and control the logging output.where the root decided to send the logs to next level or another destination.

Logging={
    version: 1,
    formatters: {
        simple: {
            format: '%(asctime)s - %(name)s - %(levelname)s - %(messas'
              },
                },
      handlers: {
          console: {
              class: 'logging.StreamHandler',
              level: 'DEBUG',
              formatter: 'simple',
              stream: sys.stdout
                    },
           file: {
               class: 'logging.FileHandler',
               level: 'INFO',
               formatter: 'simple',
               filename: 'app.log'
                    }
                    },
       loggers: {
           'root': {
               handlers: ['console', 'file'],
               level: 'DEBUG',
               propagate: False
           }
       }     
}

            

LOGS ARE THE AUDIT TRAIL OF THE SYSTEM

• Log only critical and error on console
• always enable rotation for log files

This is the most underrated aspect of software development.but the most important one.

Logginglogs