Building a Thread-Safe Logger Service from Scratch

1. What is a Logger Service and Why Does Every App Need One?

Imagine you deploy a payment service to production. A user reports their transaction failed. You have no idea why. The database is up, the servers are running — but something went wrong somewhere. How do you find out what happened?

This is exactly why logging exists. A logger service records events as your application runs — what happened, when it happened, and on which thread. These records are written to a console, a file, or a remote storage system so engineers can read them later when something goes wrong.

A good logger service needs to answer three questions at any point in time:

• What happened? — the message
• How serious was it? — the level (INFO, ERROR, etc.)
• When and where? — the timestamp and the thread name

2. What Are Log Levels and Why Do They Exist?

Not all log messages are equally important. A message that says "user profile loaded successfully" is very different from "database connection lost". Log levels let you express that difference.

public enum LogLevel {
  DEBUG(1), INFO(2), WARN(3), ERROR(4), FATAL(5);

  private final int level;

  LogLevel(int level) { this.level = level; }

  int getLevel() { return level; }

  public boolean isMinimumLevel(LogLevel threshold) {
    return this.level >= threshold.getLevel();
  }
}

So ERROR.isMinimumLevel(WARN) returns true. DEBUG.isMinimumLevel(INFO) returns false — filtered out.

3. The Minimum Level Config — How Real Services Use Levels

Here is something every real production service does: it configures a minimum log level. Any message below that level is silently ignored.

This is configured per destination. You might have:

• Console → minimum level INFO (normal operation visibility)
• File → minimum level DEBUG (full detail for investigation)
• Alert system → minimum level ERROR (only page on-call for serious issues)

The same log message can go to some destinations and be ignored by others — all based on each destination's configured minimum level.

4. Designing the Core Data — LogRecord

Before writing any logic, we need a data container that represents a single log entry. This is the LogRecord.

@Getter
public class LogRecord {
  private final long timeStamp;
  private final String threadName;
  private final String message;
  private final LogLevel logLevel;

  LogRecord(String message, LogLevel logLevel) {
    this.message    = message;
    this.logLevel   = logLevel;
    this.threadName = Thread.currentThread().getName();
    this.timeStamp  = System.currentTimeMillis();
  }
}

The @Getter annotation (Lombok) generates getters for all fields. No setters — intentionally. Once created, a LogRecord is frozen.

5. Formatter — The Strategy Pattern

Different destinations need the log in different formats. A file might need JSON so it can be parsed by a log aggregator. A console might need plain readable text. A monitoring system might need XML.

We model this with a Formatter interface. Every formatter takes a LogRecord and returns a String — the formatted output ready to write.

public interface Formatter {
  String format(LogRecord logRecord);
}

// Plain text: [2026-06-09 10:23:01] [thread-1] INFO - user logged in
public class TextFormatter implements Formatter {
  @Override
  public String format(LogRecord record) {
    return "[" + record.getTimeStamp() + "] "
         + "[" + record.getThreadName() + "] "
         + record.getLogLevel() + " - "
         + record.getMessage();
  }
}

// JSON: {"timestamp":...,"thread":"thread-1","level":"INFO","message":"user logged in"}
public class JsonFormatter implements Formatter {
  @Override
  public String format(LogRecord record) {
    return "{\"timestamp\":" + record.getTimeStamp()
         + ",\"thread\":\"" + record.getThreadName() + "\""
         + ",\"level\":\"" + record.getLogLevel() + "\""
         + ",\"message\":\"" + record.getMessage() + "\"}";
  }
}

6. Sink — The Physical Writer

A Sink is the component that actually writes bytes somewhere — console, file, network socket. It is intentionally kept thin. A Sink knows nothing about log levels or formatting. It receives a ready-made String and writes it. That is its entire job.

public interface Sink {
  void write(String formatted);
}

public class ConsoleSink implements Sink {
  @Override
  public void write(String formatted) {
    synchronized (this) {
      System.out.println(formatted);
    }
  }
}

The synchronized(this) block is critical — we will explain exactly why in the concurrency section below.

7. Destination — Putting It All Together

A Destination is the coordinator. It composes three things:

• A minimum LogLevel — the threshold filter
• A Formatter — how to format the record
• A Sink — where to write it

Example: ERROR threshold + JsonFormatter + FileSink = only ERROR and above, in JSON, written to a file.

public class Destination {
  private final LogLevel level;
  private final Sink sink;
  private final Formatter formatter;
  private final LinkedBlockingQueue<LogRecord> queue = new LinkedBlockingQueue<>(1000);

  Destination(LogLevel level, Sink sink, Formatter formatter) {
    this.level     = level;
    this.sink      = sink;
    this.formatter = formatter;

    Thread consumer = new Thread(() -> {
      while (true) {
        try {
          LogRecord record = queue.take();
          if (record.getLogLevel().isMinimumLevel(level))
            sink.write(formatter.format(record));
        } catch (InterruptedException e) {
          Thread.currentThread().interrupt();
          break;
        }
      }
    });
    consumer.start();
  }

  public void send(LogRecord record) {
    queue.offer(record); // non-blocking: drops record if queue is full
  }
}

8. Logger — The Entry Point

Logger is what your application code actually calls. It is the public face of the entire system. Its job is simple:

1. Receive a message and level from the caller
2. Create a LogRecord
3. Broadcast it to every registered Destination

Logger does not filter. It does not care about levels. It just creates and broadcasts. Each Destination decides for itself whether to act.

public class Logger {
  private final List<Destination> destinations;

  Logger(List<Destination> destinations) {
    this.destinations = destinations;
  }

  private void log(LogLevel level, String message) {
    LogRecord record = new LogRecord(message, level);
    for (Destination destination : destinations) {
      destination.send(record);
    }
  }

  public void info(String message)  { log(LogLevel.INFO, message); }
  public void error(String message) { log(LogLevel.ERROR, message); }
  public void debug(String message) { log(LogLevel.DEBUG, message); }
  public void warn(String message)  { log(LogLevel.WARN, message); }
}

Destination consoleDestination = new Destination(LogLevel.INFO, new ConsoleSink(), new JsonFormatter());
Destination fileDestination    = new Destination(LogLevel.DEBUG, new FileSink("app.log"), new TextFormatter());

Logger logger = new Logger(List.of(consoleDestination, fileDestination));

logger.info("User logged in");  // goes to both
logger.debug("Cache miss");     // file only (below INFO for console)
logger.error("DB timeout");     // goes to both

9. Design Patterns Used — Observer and Strategy

10. Concurrency — Where Does the Lock Live?

Your application runs with many threads simultaneously. A web server might have 200 HTTP threads all calling logger.info() at the same time. What happens?

11. The Problem With Synchronous Logging

In the synchronous version, the caller thread (your HTTP thread) does everything — creates the record, formats it, and waits for the sink to finish writing. If the sink is a slow network or a busy file on disk, the caller thread is blocked the entire time.

Thread-1: [business logic: 5ms] [waiting for FileSink lock: 50ms] = 55ms total
Thread-2: [business logic: 5ms] [waiting for FileSink lock: 50ms] = 55ms total
...200 threads all queueing for the same lock

In a server handling 10,000 requests per second, logging can become the bottleneck. Threads pile up waiting for the lock. Latency climbs. All because of logging — a side concern that should never impact core business logic.

12. Async Logging — The BlockingQueue Solution

The fix: decouple the caller from the writer using a queue.

• Caller thread drops the LogRecord into a LinkedBlockingQueue and immediately returns
• A dedicated background thread drains the queue and calls sink.write()

Thread-1: [business logic: 5ms] [queue.offer: 0.1ms] = 5.1ms total ✓
Thread-2: [business logic: 5ms] [queue.offer: 0.1ms] = 5.1ms total ✓
...200 threads all free

Background thread: drains queue, writes to sink at its own pace

13. Full Architecture Summary

Written as an LLD interview prep walkthrough — covering immutability, Strategy pattern, Observer pattern, synchronized blocks, ReentrantLock, LinkedBlockingQueue internals, and async producer-consumer logging architecture.