DEV Community: Amirsaeed S Komjani

10,000 Users. One Live Price. How Stale Is Too Stale?

Amirsaeed S Komjani — Wed, 02 Sep 2026 08:44:22 +0000

Imagine you are building a platform where users can buy and sell gold, silver, commodities, or crypto.

At first, everything looks fine. The system is responsive, the APIs are fast enough, and the database seems perfectly capable of handling the traffic. Then the number of users starts growing.

Now a few thousand people are looking at the same market at almost the same time. Prices need to stay fresh, balances need to remain accurate, orders should not be placed against outdated data, and charts are constantly refreshing in the background.

At this point, a very simple problem starts becoming expensive: the system keeps doing work it has already done.

The same price is requested again. The same calculation runs again. The same query reaches the database again. The same downstream service is called again, even though the answer may not have changed at all.

This is usually the moment when caching enters the conversation.

And very often the first suggestion is something like: “Let’s put Redis in front of it.”

That may help, but it does not really answer the important question.

The real question is: which data are we actually allowed to cache?

A live gold price for two seconds may be acceptable in one system and completely unacceptable in another. An order book may tolerate only a fraction of a second. A product description can probably remain stale for several minutes without anyone noticing.

But what about a user’s available balance?

What about available credit?

What about a price used to execute a financial transaction?

If a user completes a trade based on data that is only a few seconds old, are we still dealing with a performance issue, or have we created a business problem?

This is where I think caching becomes much more interesting than it first appears.

The same problem exists in large e-commerce platforms. Thousands of users may open the same product page, and most of what they need is identical: the title, description, images, category information, and product specifications.

There is no good reason to rebuild all of that from scratch for every request.

But stock, price, discount, and availability are different. They may be changing while users are looking at the page.

If you cache nothing, your infrastructure repeatedly performs work that could have been avoided.

If you cache everything, you may show a product as available when it is already sold out, display an expired discount, or return financial information that is no longer correct.

That is the point where caching stops being a simple performance optimization and becomes an architectural decision.

And the problem is much bigger than Redis.

A browser can cache. A CDN can cache. A reverse proxy can cache. The frontend can avoid duplicate requests and reuse already-fetched data. The application can cache expensive calculations, query results, or responses from external services.

Every layer gives you an opportunity to reduce unnecessary work.

But every layer can also create another version of your system’s state that may no longer match reality.

That trade-off is the part I think is often underestimated.

Writing Cache::remember()
is easy.

Deciding what deserves to be cached, where that cache should live, how long the data may remain stale, and who is responsible for invalidating it is much harder.

TTL is not really an architecture either.

Setting a value to expire after 60 seconds sounds simple, but what happens if the underlying data changes one second after it was cached? Are we comfortable serving outdated information for another 59 seconds?

Sometimes the answer is yes.

Sometimes it absolutely is not.

And this decision usually has less to do with the caching technology itself and more to do with the meaning of the data.

A product catalogue may tolerate 30 seconds of stale information without any meaningful business impact. A dashboard may tolerate a few minutes. A live market price may tolerate only a few seconds.

A balance or credit limit may tolerate almost none.

Once you reach this point, the conversation is no longer only about response times.

It is about consistency, business semantics, and risk.

There is another problem that tends to appear only when traffic becomes large enough: cache misses can become a performance problem themselves.

Imagine that a heavily requested value expires while thousands of users are asking for it. Suddenly, a large number of requests may hit the database or pricing service at almost exactly the same time, all trying to rebuild the same cached value.

The cache that was supposed to protect your system can temporarily create a spike against the very service it was meant to protect.

This is where techniques such as request coalescing, background refresh, stale-while-revalidate, distributed locks, or jittered expiration times become useful.

But again, I do not think the important lesson is the list of techniques.

The important lesson is that caching introduces its own failure modes.

More caching does not automatically mean more scalability.

The same applies on the frontend.

Modern applications can easily generate unnecessary traffic through repeated fetching, polling, tab changes, component remounting, or multiple parts of the interface asking for the same resource independently.

It is very easy to solve one backend bottleneck while leaving the frontend constantly recreating it.

This is why I do not see caching as a backend-only concern.

It is a system-wide decision.

The browser, frontend, CDN, application layer, and database may all participate in the caching strategy, but they should not all make that decision independently.

At some point, someone needs to define what the source of truth is and how much distance from that truth each layer is allowed to have.

That is probably the biggest change in how I think about caching.

At the beginning of a developer’s career, caching often looks like a framework feature. Later, it becomes a performance tool.

But once you deal with real scale, the question changes.

It is no longer:

How should we cache this?

It becomes:

Which parts of our system’s reality are allowed to be outdated, and for how long?

And once you phrase the problem that way, many caching decisions suddenly become business decisions rather than purely technical ones.

A stale product description is probably harmless.

A stale balance may not be.

A stale market price might be acceptable for a chart but unacceptable for transaction execution.

The data can be identical, but the context in which it is used completely changes the risk.

This is also why I do not believe every early-stage product needs a sophisticated caching architecture from day one.

That would often be unnecessary complexity.

But there is a big difference between prematurely caching everything and understanding early which parts of the system may eventually require explicit freshness and consistency rules.

Waiting until the first serious performance crisis usually means these decisions are made under pressure.

And under pressure, the solution often becomes something like:

“Put it in Redis for 60 seconds and we’ll fix it later.”

Sometimes that works.

Sometimes it simply moves the problem from performance to consistency.

For me, the more interesting question is not whether a system should use caching.

It is when caching should stop being an implementation detail and become an explicit architectural decision.

I’m curious to hear from CTOs and engineers who have dealt with real scale:

At what point in a product’s growth should caching become an explicit architectural decision, rather than something added after the first performance crisis?

Why Do So Many Teams Fail at Testing?

Amirsaeed S Komjani — Fri, 12 Dec 2025 10:12:13 +0000

Why Do So Many Teams Fail at Testing?

Almost every team starts with the same optimism.

At the beginning:

TDD is declared “the right way”
“Code without tests equals bugs” becomes a mantra
Frameworks, runners, and pipelines are set up with care

Everything looks mature and professional.

Then a few months pass.

Reality slowly shows up.

Tests become painfully slow.

A small change breaks dozens of unrelated tests.

No one has time to refactor the test suite.

Test debt grows quietly.

Deadlines arrive, and management pressure increases: “Ship first, fix later.”

At that point, tests stop being a safety net.

They turn into a burden.

Teams either abandon them entirely or keep them just to satisfy metrics.

Coverage numbers look fine, but confidence is gone.

The Uncomfortable Truth About TDD

Here is the controversial part.

Classic TDD does not always work.

Many teams adopt it with enthusiasm, but without the conditions it actually requires.

Velocity drops.

Deadlines get tighter.

And eventually, even the important tests stop being written.

TDD works best when:

The domain is well understood
Uncertainty is low
Discipline is consistently high
The team treats tests as first-class code

Most real-world projects do not meet these conditions.

Requirements change.

Architecture evolves.

Time is limited.

In those environments, strict TDD often creates more friction than value.

The Real Problem Is Not Testing — It’s How We Think About It

Tests are often treated as a ritual, not as software.

But tests are software.

They have architecture.

They need maintenance.

They create coupling.

They accumulate debt.

High coverage without meaningful assertions creates a false sense of security.

A thousand fragile tests are worse than ten reliable ones.

If a test does not protect a business rule, a critical workflow, or a risky integration,

its value should be questioned.

A More Pragmatic Approach

In practice, many teams succeed with a different mindset:

Design for testability first, not test-first by default
Write tests after the design is clear enough to be stable
Focus on boundaries: core logic, integrations, critical paths
Accept that not everything deserves a test
Measure confidence, not coverage

A mix of test-after and thoughtful design often produces more resilient systems than rigid dogma.

Final Thought

Testing is not about purity.

It is about trust.

If your test suite slows you down, breaks constantly, or no longer gives confidence,

the problem is not a lack of discipline.

It is a lack of architectural thinking applied to tests.

Sometimes, fewer tests — designed better — protect a system far more than perfect coverage ever could.

What has been your experience?

Does TDD genuinely help your team, or only under very specific conditions?

When deadlines hit, are tests part of the Definition of Done — or the first thing sacrificed?

From Framework Lock-in to Building Our Own ORM

Amirsaeed S Komjani — Sat, 08 Nov 2025 10:30:41 +0000

Why we decided to build a custom ORM in a real-world project

The Problem

In one of our enterprise projects, the core requirement was clear: the
Core had to be fully independent from any framework --- so that future
migrations (to another framework or even another programming language)
would not require rewriting the business logic.
That requirement forced us to build the Core from scratch, without any
framework dependencies. The biggest challenge? Designing a
framework-agnostic Data Access Layer, which naturally led us to
build our own QueryBuilder/ORM.

Architectural Goals

Decouple domain logic from infrastructure and framework layers
Enable technology migration without rewriting domain code
Achieve full unit-testability without a real database
Gain fine-grained control over query generation and execution

Why existing ORMs didn't fit

Framework-Independent Data Layer -- Most popular ORMs are deeply tied to the lifecycle and conventions of their host framework.
Unit Testing without a real DB -- We needed to test repositories and queries with in-memory fakes.
Modular Clauses -- Each clause had to be composable and replaceable without touching the Core.
Precise Execution Control -- We required control over query batching, timing, and transaction handling.

When "build" makes more sense than "buy"

Domain requirements impose contracts that off-the-shelf ORMs can't model cleanly.
Long-term architectural stability and Core independence outweigh early speed.
The team has enough technical maturity and resources to maintain a custom data layer.
Migration cost and framework lock-in risk are expected to be high across the product's lifespan.

If these conditions aren't met, adopting a mature ORM is wiser.
Reinventing the wheel only makes sense when the wheel you need doesn't
exist.

Design Foundations

Fluent Interface -- A clean, chainable API for query construction
Clause Strategy + Factory -- Each clause implemented as a strategy; a factory orchestrates their composition
Query Context -- Carries state, bindings, and execution metadata
Collection Integration -- Returns results as a collection object supporting map, filter, paginate, and metadata
Ports & Adapters --
- Ports: Repository and QueryService as Core contracts
- Adapters: Database drivers (PDO, MySQL, PostgreSQL) and in-memory adapters for testing
Execution Pipeline -- Staged SQL building, parameter binding, secure execution, and mapping to domain models
Error Mapping -- Translates low-level DB errors into application-level exceptions

Keys to Testability

In-Memory Driver -- Executes clauses in memory for unit tests
Contract Tests -- Guarantee adapter compliance with Core interfaces
Deterministic Hydration -- Predictable mapping from raw data to domain models
Boundary Tests -- Validate that infrastructure concerns never leak into the domain

Performance and Optimization

Lazy vs. Eager Execution -- Build queries lazily, execute explicitly at defined boundaries
Batching -- Combine operations to reduce round-trips
Index-Aware Hints -- Inject DB-specific execution hints without leaking them into Core logic
Metrics Hooks -- Measure runtime performance, record counts, and detect N+1 issues

Transactions and Concurrency

Unit of Work (optional) -- Track and commit grouped changes atomically
Explicit Transactions -- Provide clear APIs for begin/commit/rollback at the adapter layer
Idempotency and Retries -- Built-in hooks for retrying critical operations safely

Pitfalls and Anti-patterns

Reinventing Active Record -- Mixing domain models with DB operations defeats independence
Infrastructure Leakage -- No low-level types or exceptions should cross Core boundaries
Low-level APIs inside Core -- The Core should talk through domain contracts, not SQL or clauses
Ignoring Migration Paths -- Always design for adapter and database version evolution

Comparison Snapshot

Eloquent: Excellent developer experience within Laravel, but tightly coupled to it
Doctrine: Highly flexible and decoupled, but heavy and complex
Custom ORM (ours): Tailored to exact architectural needs, at the cost of maintenance responsibility

Outcome

A framework-agnostic Core, portable across frameworks or even languages
Strong testability without relying on a physical database
Full control over query generation and execution paths
Greater architectural transparency and deeper engineering insight within the team

When not to take this path

The project is short-lived or framework lock-in is an acceptable risk
The team is small and can't maintain a custom data layer
Existing ORMs already meet all functional and architectural requirements

Conclusion

Building a custom ORM is both a technical and economic decision --- not
a vanity project.
If Core independence, offline testability, and precise control over data
access are your first-order priorities and your team can sustain the
maintenance cost, then this path is worth it.
Otherwise, rely on proven ORMs and keep your focus on the domain.

Framework Lock-In: Are you building a product—or just a framework extension?

Amirsaeed S Komjani — Tue, 04 Nov 2025 21:36:33 +0000

Ever looked at code that feels more like a framework demo than a real product?

Many teams proudly say: “We’ve built an independent product.”

But when you dig deeper, you realize everything — from routing to authentication — is tightly bound to the framework.

Why is this a problem?

In that scenario, your product has no independent identity.

If the framework gets deprecated tomorrow or the team shifts direction, you’ll end up rewriting everything from scratch.

That’s the danger of Framework Lock-In.

The trade-off

On the flip side, some teams intentionally give up freedom for development speed and community support.

Fair enough… but is that truly a strategy, or just convenience disguised as one?

What often gets forgotten

A real product should have its own architectural identity.

A framework should remain a tool, not the thing that defines your product.

The uncomfortable truth: many so-called “products” are really just framework extensions.

Question

Would your product survive without the framework,

or is it just a plug-in living on top of it?

What do you think?

Have you ever refactored a system that was too tied to its framework?

Why is the line between juniors and seniors so often misunderstood?

Amirsaeed S Komjani — Sat, 01 Nov 2025 14:01:58 +0000

In simpler CRUD-based projects, complex architecture quickly turns into technical debt.

Here, developers with a pragmatic, delivery-focused approach (often juniors) tend to be more effective — because business reality values simplicity and speed.

But once a project grows beyond CRUD into service-based or domain-heavy complexity, that’s where seniors show their real value.

The ability to define clear context boundaries, design proper abstractions, and think in terms of scalability and maintainability isn’t something you gain just by writing code for years.

The Real Difference

The difference between a junior and a senior is not about years of experience.

It’s about maturity — in architecture, long-term maintainability, system evolution, and even teamwork and collaboration.

I’ve seen people with 3–4 years of experience act more mature in architecture and team interaction than someone who’s been coding for a decade.

That’s why, instead of counting years on a résumé, we should assess engineering maturity.

Question for you

Have you seen juniors shine in CRUD projects, or seniors saving the day in complex systems?

Let’s discuss

Why Most Developers Misunderstand Clean Architecture

Amirsaeed S Komjani — Mon, 20 Oct 2025 10:37:52 +0000

For many, Clean Architecture is just a checklist:

A controller layer
A service layer
A repository for the database

And they think they're done.
But that's only the surface.

Common Mistakes I've Observed

Misunderstanding dependency inversion
Core classes still depend on the database or framework, while the rule
says everything should depend on business logic.

Ignoring context
Developers add ten layers for a simple CRUD app --- resulting in
over-engineering and unnecessary ceremony.

Forgetting business goals
Teams build architecture for engineering ego, not for solving real
problems.

What Real Clean Architecture Looks Like

The core runs even without a database or framework.
Tests execute fast, directly on the domain logic.
Switching frameworks or databases doesn't break the system.

From my experience, the cleanest projects had the fewest layers, but
applied the Dependency Rule and DIP correctly.

Question

Have you seen teams add complexity in the name of Clean Architecture?
Share your experience below.

Did you know your database schema might be leaking through error messages and stack traces?

Amirsaeed S Komjani — Sat, 13 Sep 2025 08:08:08 +0000

AI is now smart enough to reconstruct your database from what looks like harmless errors:

SQL errors (constraint violations, duplicate entries)
ORM/Model exceptions (table names, class names, line numbers)
NoSQL hints (like MongoDB’s “document not found” or “index violation”)

Why is this dangerous?

Attackers can gradually infer your schema:

SQL → table names, keys, relationships
NoSQL → collection names, document structures, indexes

Insight

Not all databases leak the same way:

Relational DBs often reveal too much detail.
NoSQL may leak less by default, but verbose logging or misconfiguration changes the game.

What can you do?

Never expose raw errors in production.
Use generic error handling.
Regularly audit your API responses.

What about you?

Have you ever seen a “simple” DB error reveal way too much?
If you had to choose: SQL with verbose errors or NoSQL with misconfig risks — which one feels safer to you, and why?

Your API Security Assumptions Are Outdated: AI Isn’t Just a User — It’s an Attacker

Amirsaeed S Komjani — Tue, 02 Sep 2025 07:31:50 +0000

AI isn’t just a user — it can be an attacker.

Most teams still think securing an API means:

Using JWT
Enforcing HTTPS
Applying Rate Limiting

That used to be enough.

But today’s reality is different:

AI is reading and analyzing your responses.

Unlike human users, AI can:

Process millions of API responses
Extract patterns from error messages
Reverse-engineer your system faster than any human hacker

Real-World Vulnerabilities

Here’s how your API might already be leaking knowledge:

Raw stack traces → Reveal your framework and version → AI maps it to known CVEs in seconds.
Exposed SQL queries → Reveal your schema and business logic → Free blueprint for attackers.
Detailed validation errors → Help AI learn your internal rules and edge cases.

📉 The Result?

You’re handing over your system’s architecture to an intelligent attacker — for free.

🛡 Practical Steps to Protect Your API

Obfuscation

Return generic error codes/messages — not full details.
Response Layer

Sanitize and filter every outgoing response.
AI-aware Security

Assume your API is consumed by a learning model, not just a user.

💡 My Take

Once we shifted our mindset from "protecting data" to "protecting knowledge",

many risks simply disappeared.

Your Turn

Do you think AI is becoming:

a helper for security?
or the next big threat?

Let’s discuss in the comments 👇

👉 Follow me for more insights on Software Architecture + Security in the AI Era

Why Design Patterns Often Fail in Real Projects

Amirsaeed S Komjani — Mon, 25 Aug 2025 10:45:55 +0000

📉 Honestly, I’ve seen it many times: instead of helping, Design Patterns end up making projects worse.

Common reasons why they fail

Copied directly from books/tutorials without understanding the why and when.
Forcing every problem into a Pattern → pure over-engineering.
Team members interpret patterns differently → inconsistent, bloated code.
Architecture evolves, but rigid implementations stay stuck.

💡 How to make them work (from a CTO’s perspective)

A pattern is a tool, not the goal. Use it only when it solves a repeatable problem.
Align the chosen pattern with the architecture vision & product strategy, not just personal taste.
Make sure the whole team understands why this pattern was picked — otherwise, failure is guaranteed.
Keep the architecture flexible and refactor-friendly.

👉 My take? The most successful patterns I’ve seen were the ones that became a shared language for the team — not a handcuff.

Your turn: Have you seen a Design Pattern cause more pain than value?

Why Most Refactors Fail — And How to Fix Them

Amirsaeed S Komjani — Sun, 17 Aug 2025 08:05:37 +0000

“We should refactor the whole thing…”

I've heard this line more times than I can count — and honestly, most of those refactors failed.

Not because refactoring is a bad idea. But because they were done wrong.

📉 Why They Fail

Here are the top reasons I’ve seen (and experienced):

No clear target architecture

“We just want it cleaner” is not a plan.
Lack of test coverage

If you don’t have a safety net, every change is a risk.
Big-bang rewrites

Trying to change everything at once = chaos.
Team misalignment

If everyone has a different definition of “clean,” good luck.

✅ How to Do It Right

If you want your refactor to succeed, start with these:

Define the end goal

What will the architecture look like after refactoring?
Refactor incrementally

Small, focused changes are easier to test, review, and roll back.
Write tests first

Ensure you’re not breaking things while cleaning things up.
Align the team on standards

Agree on patterns, formatting, naming — everything.

💡 My Take

The best refactors I’ve seen had these 3 things:

A clear vision
A solid test suite
A well-communicated plan

Refactoring without those? You’re just rewriting code and hoping for the best.

🙋 Your Turn

Have you ever done a big refactor?

Was it painful or satisfying?
Did you have the plan and tests?
Or was it more like “rip it out and hope”?

Let’s share some refactor war stories in the comments. 👇

Repository Layer: Decoration or Real Architecture?

Amirsaeed S Komjani — Fri, 15 Aug 2025 17:17:02 +0000

Many developers add a Repository Layer to make their projects look cleaner and more professional.

But in reality, if all repositories are silently coupled to a single driver like Laravel Eloquent, this layer becomes decorative and useless.

In this post, I’ll explain why that happens, the architectural risks behind it, and how to design a Repository Layer that actually delivers on its promise.

Problem

The issue surfaces when you need to switch databases or introduce a new driver.

Instead of swapping drivers smoothly, you’re forced into a major refactor because your Repository Layer is tightly bound to one specific ORM or database driver.

The Real Purpose of the Repository Layer

A well-designed Repository Layer should:

Allow replacing or adding multiple drivers without touching your services or controllers.
Keep your application multi-driver and even multi-tenant ready.

When implemented correctly, it becomes the abstraction boundary between your domain logic and your data sources — not just an extra file to look “professional.”

How to Fix It — Adapter Pattern to the Rescue

To truly decouple your dependencies:

Define Repository Interfaces in your domain layer.
Create Adapter Classes that translate interface methods into driver-specific implementations.
Use Dependency Injection so your services/controllers depend on the interface, not the concrete driver.

Example in Laravel/PHP:

interface UserRepositoryInterface {
    public function findByEmail(string $email);
}

class EloquentUserRepository implements UserRepositoryInterface {
    public function findByEmail(string $email) {
        return User::where('email', $email)->first();
    }
}

Now, swapping to another driver (e.g., MongoDB) means creating a new adapter without touching the rest of your codebase.

Key Question for You

How do you implement your Repository Layer?
Do you leverage the Adapter Pattern to truly decouple your dependencies, or is your layer just decorative?

Conclusion

A Repository Layer is not just for aesthetics — it’s a key architectural tool for flexibility and scalability.
When paired with the Adapter Pattern, it gives you the freedom to change persistence layers with minimal effort.

💬 Have you ever had to refactor a whole project just to change the database driver? Share your experience in the comments!