ITProLab Blog

27 Jan

Ethereum Backend Architecture: Why Applications Need a Middleware Layer Between App and Node

By Max Verbin — Founder of ITProLab and ForkNews, Go Backend Architect

It’s a powerful piece of infrastructure that speaks the language of the protocol (JSON-RPC) and has absolutely no obligation to be convenient for product development.

On paper, everything looks trivial: “connect to geth, request a balance, send a transaction, get the hash.” But in practice you suddenly start writing the things you wish you didn’t have to write:

  • where to store keys and how to issue addresses from them,
  • how to restore a wallet from a seed phrase,
  • how to track incoming/outgoing transactions across a large pool of addresses,
  • how to implement “real-time” notifications instead of endless polling,
  • how all of this survives a service restart without losing state.

That’s where EthBackNode comes in - an open-source Go service that acts as an “adapter” between your application and an Ethereum node, and provides a clean JSON-RPC 2.0 API for typical backend tasks.

Why living directly with Ethereum JSON-RPC is hard (and sometimes expensive)

Ethereum JSON-RPC is the right thing, but it’s low-level. It exposes node capabilities rather than answering the question “how do I build a product?”. During integration, you quickly realize that a single task breaks down into a dozen smaller ones, and half of them aren’t even about blockchain.

For example, “accept a payment to an address”:

  1. You need to issue an address to the customer.
  2. You need to ensure the address is tied to a specific order/invoice.
  3. You need to monitor the network and detect that the transaction actually arrived.
  4. You need to wait for confirmations (and remember that reorgs happen).
  5. You need to emit an event to your backend: “payment received, you can ship”.
  6. You need to persist all this state so that a restart doesn’t pretend “nothing happened”.

If you have one order per day - you can hack it together. If you have dozens/hundreds of addresses and it matters at all for the business - engineering begins.

And here’s the key point: the average backend developer usually wants exactly one thing - a predictable API, understandable events, and minimal attack surface. Not a deep dive into “how a node works.”

What EthBackNode does

EthBackNode is a “lightweight” service you deploy next to your node (or connect to one), and your application talks to it instead. From the outside it looks like a single JSON-RPC 2.0 endpoint; inside it’s a set of modules (managers) responsible for addresses, subscriptions, transactions, and smart contracts.

Key capabilities it exposes via API:

1) Address generation and management

The service can create and manage addresses on the backend side. The important part isn’t that “an address can be generated” (you can do that yourself), but that you get a single place where an address lives as an entity: binding to your userId / invoiceId, persistence, recovery.

2) Wallet recovery from a seed phrase (BIP-39/44)

A separate pain point is wallet import and recovery. EthBackNode supports seed phrases (BIP-39) and derivation (BIP-44), so you can implement “proper” recovery flows without reinventing the wheel.

3) Monitoring incoming/outgoing transactions

The most practical part: watching addresses. The service takes on the job of “watch these addresses and tell me when something happens.” That way you don’t turn your application into a block scanner and you don’t reimplement subscription logic from scratch.

4) Transfers: ETH and ERC-20

EthBackNode can execute transfers of both native ETH and ERC-20 tokens. For a backend it looks like a single “transfer” operation rather than a collection of low-level calls and checks. It also includes fee estimation - without it you either “guess” or run extra requests yourself.

5) Callback notifications for events

Probably the feature that saves the most nerves: event notifications. Instead of asking every N seconds “did it arrive yet?”, you can configure a callback and receive events like “transaction / new block / confirmation” in your backend.

Architectural details that look boring, but solve half the problems

In services like this, what matters isn’t “lots of features,” but how it behaves in real operations.

Go + fasthttp

Performance and deployment simplicity. One binary, fast startup, predictable load handling. In crypto backends this isn’t an abstract “optimization” - it’s a basic necessity: many addresses, many events, many requests.

Node connectivity: HTTP-RPC and IPC

EthBackNode supports connecting to a node via HTTP-RPC as well as via an IPC socket. IPC is often chosen when the service and geth run on the same machine: less network exposure, fewer access-control headaches, and often simply more reliable.

BadgerDB as an embedded store

Another pragmatic choice: an embedded database without requiring external Postgres/Redis from day one. It lowers the barrier significantly: you can bring the service up, point it at a data directory, and it will persist its own state.

Configuration in HCL

HCL is a human-friendly format from the HashiCorp ecosystem. It fits infrastructure workflows (Git, reviews, environments) while being easier to read than 200-line JSON configs.

Modularity: address, subscription, transaction, contract managers

This matters more than it seems. When everything is “one big pile,” every change becomes risky. When boundaries are explicit - testing is easier, extending is easier, understanding is easier.

Where it’s truly useful

EthBackNode doesn’t try to be a “universal indexer” or an analytics platform. Its niche is applied backend infrastructure for products.

  • Payment processors: issuing deposit addresses, monitoring payments, notifications, subsequent withdrawals/sweeps.
  • Custodial wallets: address pools, withdrawals, status tracking.
  • Notification services: one component watches the chain, others consume events.
  • Backend-for-frontend: mobile/web APIs don’t know about blockchain - only about business events.
  • Exchanges and services with many addresses: mass deposit monitoring without a bespoke “scan the whole blockchain” stack.

A small example: what it might look like in an online store

Suppose you run a small e-commerce business and want to accept payments in ETH and one popular ERC-20 stablecoin.

A possible flow:

  1. The user places an order → your backend creates an orderId.
  2. Your backend asks EthBackNode for a new address for that order.
  3. Your backend registers a callback URL: “if anything arrives on this address - notify me”.
  4. The user pays.
  5. EthBackNode detects the transaction and posts an event to your callback: amount, token, hash, status.
  6. You wait for the required number of confirmations and mark the order as “paid”.
  7. On schedule (or immediately) you sweep funds to a primary cold/warm storage address.

As a result, the “crypto part” stops bleeding into your store codebase. It lives in a single service where it’s logical to maintain and test it.

Why this matters (without slogans)

In Web3, a lot of complexity isn’t “blockchain magic.” It’s plain engineering routine: addresses, keys, subscriptions, transaction status, confirmations, notifications, state persistence.

EthBackNode lowers the entry barrier for standard backend teams: instead of speaking to the node in its own language, you speak to a service in the language of tasks. And that’s probably the most useful kind of abstraction in applied crypto development: not to hide the blockchain, but to make operating it predictable.

If you have a product that must reliably receive and send ETH/ERC-20 and you don’t want to turn your core code into a pile of JSON-RPC glue — an adapter layer like this looks less like a luxury and more like common sense.

For additional technical explanations and common implementation questions, see the related Ethereum Integration FAQ section dedicated to this topic.

Author: Max Verbin — Founder of ITProLab and ForkNews, Go Backend Architect

Frequently Asked Questions

High-performance mainnet nodes in 2026 require a modern 8–12 core CPU, at least 64 GB of RAM, and a 4–8 TB NVMe SSD with high IOPS. While 16 GB of RAM is the minimum for full nodes, 64 GB or more is now the baseline for stable performance when running complex tracing or MEV-Boost services.

Synchronization stalls often occur when clients are outdated and cannot parse hard fork rules, such as the Electra upgrade. The primary solution is to update both clients immediately. For faster initialization, use "checkpoint sync" to download a trusted network state rather than rebuilding the history from genesis.

Securing a production node requires a multi-layered defense: use firewalls to restrict access, implement JWT tokens for secure communication between clients, and disable dangerous RPC namespaces like admin or debug. Use reverse proxies to enforce rate limiting and prevent resource exhaustion attacks.

An Ethereum backnode is a backend microservice, written in Go, that acts as an optimized intermediary between dApps and the blockchain. It handles critical tasks like transaction monitoring and automated transfers, abstracting node management to ensure low-latency responses and high availability without overwhelming the primary execution client.

A full node stores recent blockchain states (typically the last 128 blocks) and is sufficient for transaction validation and standard RPC calls. Archive nodes store every state change since genesis, which is essential for deep historical analytics and transaction tracing, though they require significantly more storage space, often exceeding 12 TB.

The Glamsterdam and Hegota upgrades planned for 2026 will introduce parallel transaction processing and improved state management. These protocol updates aim to increase the gas limit to 200 million and reduce storage overhead for node operators, making high-performance nodes more sustainable and decentralized in the long term.

Go-based microservices excel in transaction monitoring due to goroutines, which allow for efficient, concurrent processing of thousands of simultaneous RPC requests. By implementing a dedicated monitoring layer, developers can eliminate "node lag" and ensure that their application is not executing logic or trades based on stale chain data.

To maximize throughput, deploy dedicated node clusters and load balancers to distribute requests geographically. Offloading frequently accessed data to a caching layer like Redis and utilizing efficient RPC endpoints that support batch requests can significantly reduce latency and prevent bottlenecks during traffic spikes.