Enoch Builds

Systems Engineer | 3D Character Artist & Animator

Building systems that stay fast, stable & secure under traffic, and creating characters & digital experience

[Enoch Builds @Enoch_Builds]

I build systems and visual experiences that help products perform better, communicate clearly, and grow.

As a Full-Stack Systems Engineer, I help founders and teams build Web2/Web3 products that are fast, reliable, secure, and ready for real users.

I focus on solving problems like:

• Slow and unreliable applications
• Backend systems that struggle under growth
• Poor product architecture
• Complex user experiences
• Technical decisions that create unnecessary business costs

I work across full-stack engineering, backend architecture, infrastructure, databases, APIs, Web3, and smart contracts.

I’m also a 3D Artist & Animator, helping brands turn products and ideas into compelling 3D visuals, animations, characters, and commercial content that make people understand, remember, and want what they see.

Whether you need a system that can scale or visuals that can sell, I focus on one thing:

Creating solutions that deliver real business value.

If you're building something and need the technical or visual side solved, feel free to reach out.

[Enoch Builds @Enoch_Builds]

Bringing headphones to life with Blender!

Here's one of my 3D product animation featuring smooth rotation, realistic materials, cinematic lighting, and a sleek blue background.

Exploring the art of product visualization, one render at a time. What do you think of the final result?

[Enoch Builds @Enoch_Builds]

CPU, memory, and network influence every engineering decision, but they solve different problems.

CPU determines how quickly work is computed. Memory shapes how efficiently data is stored and accessed. Networks determine the latency and reliability of communication between systems.

Confusing these costs leads to expensive fixes.

A slow request does not need more CPU. It may be waiting on a database query, allocating excessive memory, or making remote calls. Adding threads or servers can increase costs without addressing the bottleneck.

When designing backend systems, I start by identifying where time is spent: computation, memory access, or network round trips. Then I optimize the critical path and measure the result.

The business impact is clear: faster customer experiences, more predictable capacity, and infrastructure spending aligned with constraints.

Good engineering is not about maximizing every resource. It is about understanding which resource limits the system.

Which bottleneck has surprised you in production?

#SoftwareEngineering #SystemDesign #BackendEngineering

[Enoch Builds @Enoch_Builds]

EXPLORING TREE BARK TEXTURES | BLENDER 3D
Another step in my 3D learning journey!

This time, I experimented with creating a tree bark material and applying it to two simple shapes: a cylinder and a sphere.

My focus was on capturing natural bark patterns, surface details, grain direction, and colour variations.

It's fascinating how textures can transform basic geometry into something organic.

What do you think of the result?

#MaterialStudy #CGI

[Enoch Builds @Enoch_Builds]

More threads do not automatically mean better performance.

In concurrent systems, adding threads can improve throughput, but only when the workload supports parallel execution. Otherwise, scheduling overhead, context switching, lock contention, and cache interference can cancel out the gains.

While building a Rust financial order-matching engine, I explored how different coordination strategies affect performance.

I compared shared mutexes, thread-local counters, and atomic counters with adjacent versus padded memory layouts.

The experiments highlighted how coordination and memory access patterns affect performance. These were synthetic benchmarks, not equivalent trading workloads.

For the matching engine, I chose a single-writer architecture with bounded message passing to reduce shared-state contention and keep order processing deterministic.

Concurrency is a design trade-off, not a performance shortcut.

Measure throughput, CPU utilization, contention, and tail latency under realistic loads before adding threads.

Where have you found fewer threads outperforming more in real production environments?

#Rust #Concurrency #SystemsEngineering

[Enoch Builds @Enoch_Builds]

BRINGING CHARACTERS TO LIFE | 3D WALK CYCLE ANIMATION
From static models to movement!

This time, I explored character animation in Blender by creating a walk cycle and experimenting with camera angles to capture the movement from different perspectives.

One thing I'm discovering about 3D animation is that even something as simple as walking involves a lot of details.

The timing of each step, the movement of the arms, body coordination, and the overall flow all contribute to making a character feel alive.

What I focused on:

Character movement and walk cycle animation
Timing and coordination
Camera positioning and different viewing angles
Creating a simple 3D environment
It's another step in my journey of learning 3D animation, and there's still plenty of room for improvement.

For the animators here, what would you suggest I improve in this walk cycle?

#Blender3D #3DAnimation #WalkCycle #CharacterAnimation #BlenderCommunity #3DArt #AnimationPractice #CGI #LearningBlender

[Enoch Builds @Enoch_Builds]

One of the most expensive performance problems is choosing the wrong data structure.

While building a financial order-matching engine in Rust, I explored how memory layout affects execution speed.

The business concern was straightforward: trading systems must process orders quickly and predictably, particularly under heavy workloads.

But faster hardware does not automatically solve inefficient memory access.

I benchmarked two approaches:

• Array of Structures (AoS): 17.8 ms
• Structure of Arrays (SoA): 6.3 ms

For the same quote-scanning workload, SoA was approximately **2.8 times faster**.

The improvement came from organizing frequently accessed data in a way that better supports CPU cache utilization.

However, this does not mean SoA is universally better. The right memory layout depends on access patterns, update frequency, and system requirements.

Performance optimization should follow evidence, not assumptions.

Before introducing concurrency, additional infrastructure, or architectural complexity, understand how data moves through memory.

Sometimes, the most valuable optimization is not doing more work faster.

It is making the CPU do less unnecessary work.

How often do you evaluate memory access patterns before optimizing application performance?

[Enoch Builds @Enoch_Builds]

FROM SIMPLE GEOMETRY TO A WATERMELON | 3D MATERIAL STUDY

Another day exploring the possibilities of materials and textures in Blender.

This time, I worked on creating a watermelon, focusing on its distinctive green stripes, colour variations, surface texture, and reflections.

One thing I'm learning about 3D art is that modelling the shape is only part of the process. The real challenge is making the material convincing.

For this project, my focus was on:

Creating the watermelon skin pattern
Exploring colour variation and texture details
Adjusting surface roughness and reflections
Improving material realism through lighting
Still learning, experimenting, and refining my skills with every project.

How realistic does this watermelon look to you? What would you improve?

[Enoch Builds @Enoch_Builds]

A financial trading engine can be fast and still be dangerously wrong.

That was one of the key engineering lessons from building a low-latency financial order-matching engine in Rust.

In financial systems, performance matters. But incorrect order execution, broken price priority, or inconsistent state can create risks that speed alone cannot solve.

I designed the engine around a single-writer architecture, bounded message passing, integer-based pricing, FIFO order matching, and self-trade prevention.

The implementation also explored cache-efficient memory layouts, lock contention, and predictable execution latency.

The results from local synthetic benchmarks:

• p50 latency: 48 nanoseconds
• p99 latency: 56 nanoseconds
• p99.9 latency: 69 nanoseconds
• All 14 integration tests passed.

These measurements reflect isolated engine operations, not end-to-end trading performance.

One important lesson stood out:

Low latency is a performance characteristic. Financial correctness is a system requirement.

The next challenge is ensuring deterministic recovery, durable execution records, and reliable risk controls.

How do you balance performance and correctness when designing financial systems?

[Enoch Builds @Enoch_Builds]

EXPLORING THE BEAUTY OF WOOD TEXTURES | 3D MATERIAL STUDY
Turning simple geometric shapes into realistic wooden surfaces.

This project explores the beauty of wood through texture creation, material application, colour variation, and lighting. From the natural grain patterns on the sphere to the detailed wooden plank, the goal was to capture the warmth and organic character of real wood.

Every detail contributes to making a simple 3D object feel more natural and visually appealing.

The focus:

Wood texture and grain detailing

Material creation and application

Surface finish and reflections

Lighting and rendering

Realistic material representation

A reminder that great 3D art isn't just about modelling objects; it's also about understanding the materials that bring them to life.

What do you think of this wood material study?

#3DArt #Blender3D #3DModeling #ProceduralTexturing #WoodTexture #MaterialStudy #3DRendering #CGI #DigitalArt

[Enoch Builds @Enoch_Builds]

EXPLORING THE BEAUTY OF WOOD TEXTURES | 3D MATERIAL STUDY
Turning simple geometric shapes into realistic wooden surfaces.

This project explores the beauty of wood through texture creation, material application, colour variation, and lighting. From the natural grain patterns on the sphere to the detailed wooden plank, the goal was to capture the warmth and organic character of real wood.

Every detail contributes to making a simple 3D object feel more natural and visually appealing.

The focus:

Wood texture and grain detailing

Material creation and application

Surface finish and reflections

Lighting and rendering

Realistic material representation

A reminder that great 3D art isn't just about modelling objects; it's also about understanding the materials that bring them to life.

What do you think of this wood material study?

#3DArt #Blender3D #3DModeling #ProceduralTexturing #WoodTexture #MaterialStudy #3DRendering #CGI #DigitalArt

[Enoch Builds @Enoch_Builds]

One of the most important decisions in financial software is knowing when not to calculate a number.

While working on reporting features, some figures could be derived confidently from recorded sales, expenses, purchases, and inventory.

Others could not.

A complete balance sheet requires information such as cash balances, liabilities, equity movements, and later customer or supplier settlements.
If the system does not track those events, generating a “complete” balance sheet would create false confidence.

So I chose to expose the missing information instead of inventing it.
That may make the feature look less complete, but it makes the system more trustworthy.

Good financial software is not measured by how many numbers it can display. It is measured by whether users can trust the numbers it does display.

[Enoch Builds @Enoch_Builds]

A system being “up” does not mean it is healthy.

Customers can experience slow responses, failed transactions, or inconsistent behavior while every server still appears online.

That is why observability matters.

I want a production system to answer simple questions quickly:
What failed?
When did it start?
Who was affected?
Where did the delay happen?
What changed before the problem appeared?

Logs, metrics, and traces are not just debugging tools. They reduce the time between discovering a problem and understanding it.

Good engineering is not only about building systems that work. It is also about making failures easy to detect, explain, and resolve.

[Enoch Builds @Enoch_Builds]

@UncleMo25 @TosinOlugbenga it is not by adding it to prompt, there are some implementation that doesn't need it at some point, if done at that point, it becomes over engineering, which might bring more overhead cost.

[Enoch Builds @Enoch_Builds]

A cancelled request does not always mean the work has stopped.

Imagine a customer making a payment. The payment provider successfully authorizes the transaction, but the application times out before confirming the order.

From the customer's perspective, the payment appears unsuccessful. But the money may already have been authorized.

If the customer retries without the system checking the previous attempt, they could end up with duplicate transactions.

This is why I pay attention to how systems handle interrupted operations.
A timeout, cancellation, or worker failure should not leave the application in an uncertain state.

I consider questions like:

What work has already been completed?
Can the operation safely resume?
Could retrying create duplicate effects?
Does the system know whether the previous attempt actually succeeded?

These decisions matter because interruptions are inevitable in distributed systems.

Reliable software is not just about handling successful operations. It is about ensuring that interrupted operations can be safely recovered without creating new problems for the business or its customers.

[Enoch Builds @Enoch_Builds]

A cancelled request does not always mean the work has stopped.

Imagine a customer making a payment. The payment provider successfully authorizes the transaction, but the application times out before confirming the order.

From the customer's perspective, the payment appears unsuccessful. But the money may already have been authorized.

If the customer retries without the system checking the previous attempt, they could end up with duplicate transactions.

This is why I pay attention to how systems handle interrupted operations.
A timeout, cancellation, or worker failure should not leave the application in an uncertain state.

I consider questions like:

What work has already been completed?
Can the operation safely resume?
Could retrying create duplicate effects?
Does the system know whether the previous attempt actually succeeded?

These decisions matter because interruptions are inevitable in distributed systems.

Reliable software is not just about handling successful operations. It is about ensuring that interrupted operations can be safely recovered without creating new problems for the business or its customers.

[Enoch Builds @Enoch_Builds]

@jimoh_jomezy Thank you so much sir

[Enoch Builds @Enoch_Builds]

What do you think about this animation? Does it look interesting, or do you have a better idea?

[Enoch Builds @Enoch_Builds]

You can add more workers, more servers, or more processing power and still have a slow system.

Sometimes the real limitation is dependency.

Imagine a process with five steps, where each step needs the result of the previous one before it can begin.

No matter how much capacity you add, those steps still have to wait for each other.

That creates a different engineering question.

Instead of asking: “How can we process more things at once?”

I ask: Which parts actually depend on each other?

Which work can happen independently?

Are we forcing tasks to wait when they do not need to?

Can the critical path be shortened?

This matters because unnecessary dependencies increase response time, reduce throughput, and make scaling more expensive.

Sometimes the best performance improvement is not adding more resources.

It is redesigning the workflow so independent work can happen independently.

Scaling is not only about adding capacity. It is also about removing unnecessary dependencies that prevent the capacity you already have from being useful.

[Enoch Builds @Enoch_Builds]

I wanted these pieces to feel used rather than factory-fresh, with the lighting bringing out their rounded forms and surface details.

Which catches your eye first, the material or the lighting?

Enoch Toon Studio

#3DArt #Blender3D

[Enoch Builds @Enoch_Builds]

A system can have plenty of computing power and still become slow because too many operations are waiting on each other.

Sometimes, too many operations are waiting on each other.

Imagine a financial platform processing thousands of transactions. Several operations need access to the same information, but only one can update it at a time.

As demand grows, those small waits can accumulate.

Transactions take longer to process, customers wait longer for responses, operational backlogs grow, and adding more servers may not solve the real problem.

This changed how I think about system performance.

I do not only ask, “Can the system handle more traffic?”

I also ask:

Are important operations unnecessarily blocking each other?

Can parts of the workload operate independently?

Are we holding up critical work while performing less important tasks?

The goal is not to remove every restriction. Some coordination is necessary to protect financial correctness.

The engineering judgment is knowing where coordination protects the business and where it quietly limits growth.

Good system design is not just about processing more work. It is about reducing unnecessary waiting while keeping the results correct and reliable.