About me

I build tounderstand.

Divyam SinghSoftware engineer

Hi, I'm Divyam.

Most of what you'll find here started with a simple question:

“How does this actually work?”

View projects

Contact me

01Curious by default

02Learning through building

03Going deeper

The longer version

Curiosity is the throughline.

That curiosity has taken me through a lot of different corners of software. I've built trading engines to understand matching systems, workflow automation to explore how tools like Zapier work behind the scenes, and collaborative applications to learn what it takes to make real-time systems reliable.

I enjoy understanding software beyond the abstractions we use every day. The architecture, tradeoffs, failure cases, and small decisions that determine whether something works just well enough or works well consistently.

Right now, I'm focused on becoming a stronger software engineer, going deeper into distributed systems and infrastructure, and continuing to build products that solve interesting problems.

There's still a lot I don't know, and that's probably my favorite part about engineering. There's always something new to figure out.

Engineering focus

The work behind the interface.

The areas I keep returning to while I learn, build, and go deeper into the software behind everyday abstractions.

01 // DISTRIBUTED SYSTEMS

Systems & infrastructure

Building fault-tolerant storage, consensus layers, and high-throughput event pipelines that remain reliable under heavy load.

RustSolanaKafkaPostgreSQL

Focus: Failure path design & state recovery

02 // ENGINES & AUTOMATION

Product internals

Constructing order matching engines, mempool security analytics, and execution machinery to understand how products run under the hood.

GoTypeScriptRabbitMQRedis

Focus: Low-latency execution & execution flows

03 // CONCURRENCY & STREAMING

Real-time software

Designing WebSocket telemetry, real-time state sync, and collaborative software where consistency and instant feedback matter.

WebSocketsWebRTCNext.jsDocker

Focus: Sub-millisecond event propagation

Operating principles

Make the hard parts visible.

Effortless interfaces start with explicit limits, observable signals, and recovery paths underneath.

03 rules / always active

01 // RELIABILITYRULE

Design the failure path

Recovery behavior belongs directly inside the architecture, not buried inside a post-incident document after production breaks.

→ Graceful degradation over unhandled crashes

02 // OBSERVABILITYRULE

Measure the real system

Latency spikes, queue backpressure, retries, and state transitions must stay visible in telemetry from day one.

→ Metrics over unverified assumptions

03 // ARCHITECTURERULE

Keep boundaries explicit

Clean module ownership and typed interfaces make complex distributed systems easier to scale, test, and safely evolve.

→ Strict API contracts & domain isolation

Elsewhere online

Find the ongoing work.

Code, technical writing, and professional updates across the places I use most.

GitHub

@divyyyam

Source code, experiments, and systems currently being built.

Divyam Singh

Professional updates, engineering work, and collaboration.

@divyyyyyam

Short notes on software, infrastructure, and the build process.

Medium

@divyamsingh1905

Longer technical writing and lessons from production systems.