Why dApp architecture falls apart as load grows
A dApp architecture built for a demo holds up only until the first real users.
While requests are in the dozens, everything responds instantly; under peak load, the data layer is the first to give way — reads go directly to a network node, aren't cached, and historical event queries are rebuilt from scratch every time a screen is opened.
The queue of requests grows faster than the audience arrives, and the interface starts waiting where on staging everything was instant.
The bottleneck is almost never in the contract computations themselves — it's in how reads and writes are distributed between the network, the event indexing service, and the backend.
The second typical failure is duplicated logic. Validation rules live both in the smart contract and in the backend, and after the first change they diverge: add a field — edit it in three places, and a forgotten branch causes state desync.
Every extra write to the network increases transaction cost and confirmation time, so at peak operations queue up.
Contract updates are done manually: state migration, reissue, distribution of new addresses to clients. Without versioning and a rollback plan, the downtime window is measured in hours instead of minutes.
Separately, permissions are not segregated: one key signs both administration and payouts, so a leak equals full control over the logic.
Next we examine how these nodes are laid out at the design stage so that load growth doesn't require a rewrite.
What a well-thought-out scheme gives: measurable effect
The effect of architecture manifests not on launch day, but on the second or third iteration, when the product begins to be changed under load.
Therefore we count it in engineering values: time to ship changes, share of manual operations at release, number of incidents and classes of failures that stop occurring altogether.
Time to ship changes
The contract core is separated from mutable logic, so a new capability is released as a separate module. An update takes hours instead of reissuing the entire contract set and re-approval, while state and user balances remain in the core and require no migration.
Share of manual operations
Deployment, migrations, and address verification are described by scripts: the release is reproduced by a command on testnet and repeated on mainnet without manual edits. Manual steps remain few — only where owner key confirmation is needed.
Class of failures that goes away
Permissions are separated by roles, withdrawal limits and contract pause are prescribed in advance.
Audited standard libraries — for example, OpenZeppelin — close typical implementation errors in tokens and access control, so a failure like "one wrong action disabled the entire contract" cannot reproduce.
Number of incidents and predictability
Contract events are written to a log, alerts are configured for anomalies: growth in the share of failed transactions, a spike in calls to one function, an owner change.
The problem is visible from metrics before users notice it, and investigation starts with a ready picture, not screenshots from chat.
Approaches to dApp architecture: comparison of modes
The choice of mode determines not code style, but what edits you can make to a running product and at what cost.
Below is a comparison of the approaches actually chosen at the start: how much logic lives in one contract, what is moved to modules, and where the boundary between the network and external services lies.
Three modes and their cost
| Option | When suitable | Limitations of the approach |
|---|---|---|
| Monolithic contract | One scenario, short lifecycle, simplicity of verification matters | Editing logic requires state migration; size hits the deployment limit; an error affects the entire product |
| Modular scheme: core and modules | Logic grows, parts update independently, roles are separated | Calls between modules are more expensive, access rights and initialization order are more complex, storage layout must be careful |
| Hybrid option | Heavy computations, frequent reads, long event history | Part of the trust moves to an external service, state reconciliation and protection against divergence from the network are needed |
Comparison rarely yields one winner: monolith wins on launch speed, modular scheme on product lifespan, hybrid on operation cost.
Approach limitations appear later, when the storage layout can no longer be rewritten, so we fix the boundary between the core and the external layer before the first line of code and immediately lay a migration path from monolith to modular scheme.
Design and implementation stages: from audit to handover
The order of stages here isn't a formality: the data scheme determines both the contract logic and the interface, so changing it after assembly is more expensive than agreeing before. Below is the sequence our team follows, with a concrete result at each step.
-
Solution audit. We build a map of the current state: where data is stored, who writes and with what rights, which external services are tied to the app. The output is a list of dependencies and risks sorted by cost of error.
-
Design of data and permissions scheme. We separate entities: what must live on-chain and what remains off-chain. For each role we describe allowed actions and invariants — conditions that cannot be violated under any scenario.
-
Contract and boundary design. We split logic into modules, determine what updates and what is fixed forever, and limit the amount of data written to the network: user operation cost depends on this.
-
Assembly and local checks. We write tests for invariants and edge scenarios: repeated call, canceled operation, insufficient permissions, divergence from an external data source.
-
Testing in a test environment. We deploy a duplicate network and run scenarios at volumes close to production: load, behavior when an external service fails, update rehearsal and rollback to the previous version.
-
Publication and monitoring. We enable gradually, keep an event log and configure anomaly alerts — failure becomes visible before users notice it.
-
Project handover to the team. We hand over documentation, access, update regulations and rationale for decisions; conduct training so the system can be developed without us.
What remains with you after project delivery
A project is considered delivered not when the demo works on testnet, but when your team can deploy, update and roll back the system without us.
Therefore acceptance includes not only code, but a package of artifacts by which a new engineer restores the logic of decisions without reconstructing it from transaction logs.
- Project source code — the entire repository, with commit history, build description and fixed dependency licenses. No "private" modules that remain on our side.
- Data flow diagrams: how a call goes from the interface to the contract, where keys and state are stored, which events are written to the log and how to read them.
- Access policies and roles: the "role — operation — contract" matrix, multisignature rules, procedure for changing owner and administrators after launch.
- Deployment documentation: network and environment parameters, migration order, post-deployment verification checklist and criteria under which release is considered successful.
- Update regulations: how a new contract version is released, which access checks pass, how a planned update is announced and conducted.
- Recovery regulations: backup points for state and keys, target recovery time, responsible persons and incident procedure.
- Support instructions: typical failures and their signs, which alerts are configured, where to look first.
We agree on the package at the start, not assemble it at the end — this way documentation describes the real system, not its original concept. Before project closure, your engineers go through each item themselves: deploy a copy, make a test change, roll back. What couldn't be repeated without our hint, we refine in the documentation until it works.
Case: how a class of failures disappeared under peak loads
Peak load broke the same scenario: operations on a high-demand asset came in batches, and the entire path — reading network state, sending a signature, confirmation — went through a single intermediary service with a shared key.
The queue grew faster than it was processed, some signatures went twice, and "stuck" operations were completed manually by operators. A peak incident meant downtime, manual retrospective reconciliation and investigation of balance discrepancies.
We reworked the scheme: separated reads and writes, moved network state to a separate layer with cache and indexing, and moved signature sending to a queue with an idempotent operation key, retries and automatic fee selection.
Reconciliation moved to a background stream: the operation log is constantly compared with network state, a discrepancy raises an alert rather than a task for an operator. At the same time we fixed the contract between layers so that failure of one doesn't drag down the others.
Metrics before and after: recovery time — from 45 minutes to 6, number of incidents — from seven-eight per month to one-two per quarter, share of manual operations in investigation — from 35% to 6%.
Duplicate signatures disappeared as a class, and confirmation at peak fits into seconds instead of minutes: failures under peak loads stopped being a separate line in the report.
A separate effect is predictability. Now the peak is visible in advance by queue length and confirmation delay, and load is handled before it becomes an incident.
We describe the case based on an asset tokenization platform: figures are taken from its monitoring for three months before and three months after the scheme rework.
How does a modular scheme differ from a monolithic contract?
A monolithic contract holds in one address both state storage, logic, and access rights. It's cheaper to deploy and simpler for first verification: one code unit, one test set, fewer connections between parts. Then this wholeness begins to get in the way.
Upgradability is the first difference. To fix one logic branch in a monolith, you need to change the entire contract: an immutable option doesn't allow this, and migration via proxy risks touching storage and losing compatibility with already written data.
A modular scheme moves rules into separate parts with links — state and assets remain in an immutable core, and only the needed module changes.
The risk of funds lock grows with the number of execution paths in one address. An error in any external call of a monolith can stop withdrawals from the entire contract.
In a modular scheme, withdrawals are attached to separate storage with a minimal set of actions — harder to break, narrower error surface.
Operation cost is counted honestly: a module call is a separate transition between addresses, more expensive than an internal function call.
Separation is justified where logic will change or where request flow and balance storage should already be separated; for short immutable logic, a monolith is cheaper and more predictable.
Verifying a monolith in full means rereading all the code, including unchanged pieces. Modules allow verifying only the changed part, but require discipline in describing links and permissions.
The choice is dictated by the answer to one question: what in the project must be updated. Rules — modular scheme, nothing — monolith.
Technical doubts: integrations, limitations, access
Doubts at this stage concern not "will you do it", but operation: how the solution coexists with third-party services, what happens under network overload, who manages contracts after handover. Below are answers to the objections we hear most often.
Will the existing contract have to be rewritten?
Deployed code undergoes an audit: if logic is moved to a separate layer, refinement proceeds by module without data transfer. Reissue is needed only when the storage structure changes — then we prepare state migration and a period of parallel operation of old and new versions.
How are external services connected?
External data comes through oracles and indexers, payment and accounting systems through an adapter layer. The external call is isolated by timeouts, retries and a circuit breaker: source unavailability doesn't block user operations.
Will we hit network limitations?
Bottlenecks are cost and confirmation time during peak hours. We include batch processing, state cache and moving part of the logic off-chain where this doesn't reduce guarantees. Limits are checked by load scenarios on testnet.
Who manages permissions and security after handover?
Roles are separated by least privilege: administrative functions — to the customer's multisig with execution delay, emergency stop — to a separate key. Access is built on audited libraries, for example OpenZeppelin. We hand over key rotation regulations and incident response procedure.
Let's discuss the task: what to send for assessment and plan
Assessment of dApp architecture is faster when the input has facts, not a general description of the idea. Below is what to send so we return with a plan, not clarifying questions: for each item we either close the uncertainty immediately or ask one precise question.
- Flow diagram: who initiates the transaction, where state is stored, which data must be public and which remains off-chain.
- Roles and permissions: contract administrator, operator, user — and what each role can change without reissuing contracts.
- Calculation logic and state transitions: formulas, payout conditions, order of unlocking funds, behavior in disputed situations.
- Wallet and network requirements: which wallets users work with, whether support for multiple networks and transfers between them is needed.
- Load: expected number of operations, peak periods, sensitivity to confirmation time and operation execution cost.
- External integrations: payment gateways, external data sources, internal accounting systems, event exchange.
- What has already been done: contracts, tests, deployment scheme, repository access — if the project has started.
- Constraints: what must be ready first and which deadlines are critical for you.
Next — a call with the architect and lead contract developer: we review the scheme and mark places where on-chain logic isn't needed and it's cheaper to move it to an external service.
After that we return with an estimate, a stage-by-stage work plan — contract prototype and tests, preparation for security review, interface integration, mainnet deployment — and team composition for each stage.