Design an Extensible Logging Library

Why a logging library is the perfect LLD problem

A logging library looks deceptively simple — “just write strings to a file” — but it is one of the highest-signal machine-coding prompts because every constraint you add pulls in a different pattern. Levels pull in filtering. Multiple destinations pull in Strategy. Pluggable output formats pull in Decorator. A single global access point pulls in Singleton / a registry. Throughput and “don’t block the request thread” pull in async + a bounded queue + thread-safety. The interviewer is watching whether you can layer these without turning the design into mud.

This lesson designs the library the way you should in a 45-minute interview: clarify, model the core entities, draw the UML, nail the method signatures, then stress-test with edge cases and extensions. The reference implementation is log4j / SLF4J-shaped because that vocabulary (logger, level, appender, layout) is what your interviewer already has in their head.

In an interview, say up front: “I’ll design this like log4j — a Logger facade, pluggable Appender sinks, and Formatter layouts — because that separation is what makes it extensible. Let me confirm requirements first.” This signals you know the domain and won’t reinvent vocabulary.

Step 1 — Clarify requirements

Spend the first 3-4 minutes here. Logging has a huge surface; you score points by narrowing it deliberately rather than building everything.

Functional (the ones that matter):

• Log levels with ordering: TRACE < DEBUG < INFO < WARN < ERROR < FATAL. A logger has a threshold; messages below it are dropped cheaply.
• Multiple destinations (appenders/sinks): console, file (later: rolling file, network, DB). One log call can fan out to several.
• Pluggable formatting: 2026-06-14T10:00:00Z [INFO] [thread-1] OrderService - placed order 42. Format must be swappable without touching the logger.
• Configurability: set level, appenders, and format at startup (config object or file), not hardcoded.
• Hierarchy (optional, call it out): com.shop.OrderService inherits config from com.shop from root. This is what makes log4j log4j; I’ll mention it but keep the core flat unless asked.

Non-functional (the ones that decide your grade):

• Thread-safety: many threads log concurrently into shared appenders. Interleaved/garbled lines are a bug.
• Performance / non-blocking: an ERROR log must not stall a request thread on slow disk I/O. Async with a bounded queue.
• Reliability on shutdown: async means buffered records — you must flush before exit or lose logs.
• Extensibility: adding a KafkaAppender or a JSON format should be a new class, not an edit to existing ones (Open/Closed).

Questions to ask the interviewer (pick 2-3):

1. “Single process, or do we need network/distributed sinks?” (Scopes appenders.)
2. “Is throughput high enough to require async, or is synchronous fine?” (Decides whether you build the queue.)
3. “Do we need the logger hierarchy with inheritance, or are named loggers with explicit config enough?”
4. “On overload, do we drop logs or block the producer?” (Backpressure policy — a senior-level question.)

Step 2 — Core entities and responsibilities

The critical separation: Logger decides whether and what; Appender decides where; Formatter decides how it looks. Three axes, three abstractions. If any two of these collapse into one class, the design fails the extensibility test.

Step 3 — ASCII UML class diagram

                        +---------------------+
                        |   LoggerRegistry    |  <<Singleton>>
                        |---------------------|
                        | - loggers: Map      |
                        | + getLogger(name)   |
                        | + configure(cfg)    |
                        | + shutdown()        |
                        +----------+----------+
                                   | creates/caches
                                   v
   +-----------+   uses    +---------------+        * +----------------+
   | LogLevel  |<----------|    Logger     |----------> |   Appender    | <<interface>>
   |-----------|           |---------------|  appenders | (Strategy)    |
   | TRACE..   |           | - name        |            |---------------|
   | FATAL     |           | - level       |            | + append(rec) |
   +-----------+           | + info(msg)   |            | + flush()     |
                           | + error(msg)  |            | + close()     |
       builds              | + isEnabled() |            +-------+-------+
          |                +-------+-------+                    ^
          v                        |                __________/ | \__________
   +---------------+               | creates       |            |            |
   |  LogRecord    |<--------------+        +-------------+ +-----------+ +------------------+
   |---------------|                        | Console     | | File      | | AsyncAppender    |
   | level         |                        | Appender    | | Appender  | | (Decorator)      |
   | message       |                        +------+------+ +-----+-----+ |------------------|
   | timestamp     |                               |              |       | - delegate:      |
   | threadName    |                               | formatter    |       |     Appender     |
   | loggerName    |                               v              v       | - queue: Blocking|
   +---------------+                        +--------------------------+  | - worker: Thread |
                                            |  Formatter <<interface>> |  +--------+---------+
                                            |  (Strategy/Decorator)    |           | wraps
                                            |  + format(rec): string   |           v
                                            +-----------+--------------+     (any Appender)
                                                        ^
                                          _____________/ \______________
                                         |                              |
                              +---------------------+      +-----------------------------+
                              | PatternFormatter    |      | JsonFormatter / decorators  |
                              +---------------------+      +-----------------------------+

Step 4 — Key method signatures

Start with the contracts. In an interview, write the interfaces first — they prove the abstractions are clean before you spend time on bodies.

A couple of cross-language notes baked into the code below:

• The threadName is captured from the actual current thread in all three languages. For a problem whose whole non-functional thesis is concurrent logging, a hardcoded "main" makes the field meaningless — capture it where the log call originates.
• C++ populates a real timestampMs from system_clock so its formatted output matches the TS/Python output. Don’t leave a literal 0.
• The TS Appender.close() is typed void | Promise<void> so an async sink (the AsyncAppender below) can be honestly typed and awaited by callers, while a synchronous sink can still return void.

enum LogLevel { TRACE, DEBUG, INFO, WARN, ERROR, FATAL }

interface LogRecord {
readonly level: LogLevel;
readonly message: string;
readonly timestamp: number;     // epoch millis
readonly threadName: string;
readonly loggerName: string;
}

interface Formatter {
format(record: LogRecord): string;
}

interface Appender {
append(record: LogRecord): void; // assume level already passed
flush(): void;
close(): void | Promise<void>;   // flush + release resources (may be async)
}

class Logger {
constructor(
  private readonly name: string,
  private level: LogLevel,
  private readonly appenders: Appender[],
) {}

isEnabled(level: LogLevel): boolean { return level >= this.level; }

log(level: LogLevel, message: string): void {
  if (!this.isEnabled(level)) return;           // cheap early-out
  const record: LogRecord = {
    level, message, timestamp: Date.now(),
    // Node is single-threaded for JS; this is the worker/thread label
    // (e.g. worker_threads name). "main" here is the actual value, not a stub.
    threadName: currentThreadName(),
    loggerName: this.name,
  };
  for (const a of this.appenders) a.append(record);
}

info(msg: string) { this.log(LogLevel.INFO, msg); }
error(msg: string) { this.log(LogLevel.ERROR, msg); }
}

Step 5 — Strategy for sinks, with the formatter inside

The Appender is a Strategy: each concrete appender is an interchangeable algorithm for “where bytes go,” and the Logger is configured with whichever ones you want.

On thread-safety of the sinks — and a real cross-language difference you should call out:

• In Python and C++, multiple OS threads can hit the same appender concurrently, so ConsoleAppender and FileAppender each take a per-appender lock to prevent interleaved/garbled lines.
• In Node.js, JavaScript runs on a single thread — there is no shared-memory data race for these sinks, so no lock is needed (or possible) in the TS version. This is an intentional difference, not an oversight. Say this out loud in an interview: “Node’s single-threaded model means the synchronous-write appenders need no lock; in a JVM/C++ world I’d guard them.”

So the three implementations are equivalent in intent (a single line is never split by another), achieved by the runtime in Node and by an explicit lock in Python/C++.

class PatternFormatter implements Formatter {
format(r: LogRecord): string {
  const ts = new Date(r.timestamp).toISOString();   // "2026-06-14T10:00:00.000Z"
  // LogLevel[r.level] works because LogLevel is a *numeric* enum (reverse map).
  // Caveat: a 'const enum' or string enum would break this reverse lookup;
  // for those, keep an explicit number->name array instead.
  const lvl = LogLevel[r.level];
  return `${ts} [${lvl}] [${r.threadName}] ${r.loggerName} - ${r.message}`;
}
}

class ConsoleAppender implements Appender {
constructor(private fmt: Formatter) {}
append(r: LogRecord) {
  const line = this.fmt.format(r);
  // Call through console so 'this' stays bound (some runtimes bind console
  // methods; extracting them detached is fragile). No lock: Node is single-threaded.
  if (r.level >= LogLevel.ERROR) console.error(line);
  else console.log(line);
}
flush() {}
close() {}
}

class FileAppender implements Appender {
// Node fs handle elided; pretend writeLineSync appends a line synchronously.
constructor(private fmt: Formatter, private fd: number) {}
append(r: LogRecord) {
  const line = this.fmt.format(r) + "\n";
  // No lock needed: JS runs on one thread, so append() calls cannot interleave.
  // A single synchronous fd write also keeps the line atomic at the OS level.
  writeLineSync(this.fd, line);
}
flush() { fsyncSync(this.fd); }
close() { this.flush(); closeSync(this.fd); }
}

With the same record, all three now emit the equivalent line:

2026-06-14T10:00:00.000Z [INFO] [thread-1] OrderService - placed order 42

Step 6 — Async with a bounded queue (Decorator + Producer/Consumer)

This is the component interviewers actually care about, and the one most candidates get wrong. The requirement: an ERROR call must not block the request thread on slow disk I/O. The solution: AsyncAppender is a Decorator — it is an Appender and wraps an Appender — that enqueues records and drains them on a dedicated worker thread.

Three things must be correct, and they are the scoring rubric:

1. Bounded queue. Unbounded means a slow sink + fast producer = OOM. Bound it.
2. A stated backpressure policy when the queue is full: block the producer (lossless, but can stall) or drop (lossy, but never stalls). State which and why. Below I implement drop-newest with a dropped-count — common for logging because losing a log is better than stalling a request — and note how to switch to blocking.
3. close() must drain the queue AND join the worker before returning. If you return before the worker finishes, buffered logs are lost — which directly violates the “flush before exit” requirement.

There is one subtlety unique to the single-threaded TS version: the drain loop parks on a Promise when the queue empties, so append() must wake it on every enqueue, not only at close(). The threaded versions get this for free — Python’s queue.get(timeout=...) repolls and C++‘s cv_.notify_one() signals the consumer on each push. The TS code below mirrors that by capturing and invoking the parked resolveIdle callback inside append(). Forget that step and you get a classic lost-wakeup bug: records sit undrained until shutdown.

// Node: no shared-memory threads, but I/O is async. We simulate a "worker"
// with an async drain loop; backpressure is by queue length. The semantics
// (bounded buffer, drop-on-full, drain-on-close) mirror the threaded versions.
class AsyncAppender implements Appender {
private queue: LogRecord[] = [];
private dropped = 0;
private closed = false;
private draining: Promise<void>;
private resolveIdle?: () => void;

constructor(
  private delegate: Appender,
  private capacity = 8192,
) {
  this.draining = this.drainLoop();
}

append(r: LogRecord): void {
  if (this.closed) return;
  if (this.queue.length >= this.capacity) { this.dropped++; return; } // drop-newest
  this.queue.push(r);
  // Wake a parked drain loop so newly enqueued records are processed
  // promptly (mirrors Python put_nowait / C++ cv_.notify_one on enqueue).
  // Without this, a worker that went idle stays asleep until close() and
  // buffered records are never drained in steady state — a lost-wakeup bug.
  const wake = this.resolveIdle;
  this.resolveIdle = undefined;
  wake?.();
}

private async drainLoop(): Promise<void> {
  while (!this.closed || this.queue.length > 0) {
    const r = this.queue.shift();
    if (r === undefined) {
      if (this.closed) break;
      await new Promise<void>(res => (this.resolveIdle = res)); // wait for work/close
      continue;
    }
    this.delegate.append(r);
  }
}

flush(): void { this.delegate.flush(); }

async close(): Promise<void> {
  this.closed = true;
  const wake = this.resolveIdle;       // wake the loop so it can finish
  this.resolveIdle = undefined;
  wake?.();
  await this.draining;                 // drain remaining records ("join")
  if (this.dropped > 0) console.error(`AsyncAppender dropped ${this.dropped} records`);
  this.delegate.flush();
  this.delegate.close();
}
}

Step 7 — Singleton registry (global access without globals)

Loggers are obtained by name and must be shared (two calls to getLogger("OrderService") return the same logger). That is a Singleton registry plus a Factory method, with a cache. Make creation thread-safe (double-checked or a lock) and have shutdown() close every appender — that is what triggers the async drain on exit. Because the TS AsyncAppender.close() is async, the TS shutdown() is itself async and awaits each close(); returning before those promises settle would discard in-flight records, the exact return-before-drain defect the warn callout above condemns.

class LoggerRegistry {
private static instance: LoggerRegistry;
private loggers = new Map<string, Logger>();
private defaultLevel = LogLevel.INFO;
private defaultAppenders: Appender[] = [];

private constructor() {}

static getInstance(): LoggerRegistry {
  if (!LoggerRegistry.instance) LoggerRegistry.instance = new LoggerRegistry();
  return LoggerRegistry.instance;
}

configure(level: LogLevel, appenders: Appender[]): void {
  this.defaultLevel = level;
  this.defaultAppenders = appenders;
}

getLogger(name: string): Logger {
  let lg = this.loggers.get(name);
  if (!lg) {
    lg = new Logger(name, this.defaultLevel, this.defaultAppenders);
    this.loggers.set(name, lg);          // single-threaded: no lock needed
  }
  return lg;
}

async shutdown(): Promise<void> {         // closes shared appenders -> async drain
  // await each close so AsyncAppender.close() fully drains its queue
  // before shutdown() returns (return-before-drain loses buffered logs).
  for (const a of this.defaultAppenders) await a.close();
}
}

Step 8 — Edge cases interviewers probe

Step 9 — Patterns recap and extensibility

“What if they ask for…” — rehearse these; each is a clean extension, not a rewrite:

• A JSON format? New JsonFormatter implements Formatter. Zero changes elsewhere — that’s the Strategy payoff.
• Rolling files by size/date? New RollingFileAppender (a sink variant), or a BufferingAppender decorator. The Logger is untouched.
• Per-level routing (ERROR→Slack, INFO→file)? A FilterAppender decorator wrapping each sink, or a composite appender that checks level. Decorator again.
• The logger hierarchy (com.shop.OrderService inherits from com.shop)? Store loggers in the registry by dotted name; on getLogger, walk up to the nearest configured ancestor for effective level/appenders. The LogRecord/Appender/Formatter contracts don’t change — only the registry’s resolution logic.
• Structured/contextual logging (MDC)? Add a thread-local context map merged into each LogRecord. New field, same flow.

Closing line for the interview: “Every extension here is a new class implementing an existing interface or a new decorator — never an edit to Logger, Appender, or Formatter. That Open/Closed property is the whole reason for the three-axis split.” That sentence is the one that gets you the senior checkmark.