DEV Community: anuj kumar

DDD, N-Layer and Microservices are not competing architectures.

anuj kumar — Fri, 09 Oct 2026 17:33:42 +0000

Yet they’re still discussed that way surprisingly often.
The mistake is comparing them at the same level.
DDD asks:
How do we model a complex business domain correctly?
N-Layer asks:
How do we organise technical responsibilities cleanly?
Microservices ask:
How do we split a distributed system into independently deployable business capabilities?

Those are three very different questions.
And in a real system, you may use all three.
For example, an Order microservice could represent an Ordering bounded context, use DDD to protect invariants around orders and payments, and still structure its internals into application, domain, and infrastructure layers.

The architecture lesson is simple:
Don’t start with the pattern. Start with the problem.
If the problem is domain complexity → think DDD.

If the problem is code separation → think layers.

If the problem is independent deployment, scaling, and ownership → think microservices.

Architecture gets much clearer when we stop asking:
“Which architecture is best?”
and start asking:
“Which architectural problem am I solving?”

SoftwareArchitecture #DDD #DomainDrivenDesign #Microservices #SystemDesign #DistributedSystems #Java #SpringBoot #SoftwareEngineering #TechnicalArchitecture

🔐 Encryption vs Digital Signatures: Understanding the Difference

anuj kumar — Fri, 09 Oct 2026 17:29:31 +0000

Auth 2.0 + PKCE Explained: Understanding the Complete Authentication Flow

anuj kumar — Fri, 09 Oct 2026 17:24:37 +0000

OAuth 2.0 + PKCE Explained: Understanding the Complete Authentication Flow
Ever wondered what actually happens behind the scenes when you click “Sign in with Google/Microsoft/etc.”?
This diagram breaks down the OAuth 2.0 Authorization Code Flow with PKCE, step by step from the user authentication request to the final API access token.
If you're learning OAuth 2.0, OIDC, or API security, this diagram should make the flow much easier to understand.

OAuth 2.0 + OIDC + PKCE Explained: From Login to API Access 🔐

anuj kumar — Fri, 09 Oct 2026 17:13:05 +0000

OAuth 2.0 + OIDC + PKCE Explained: From Login to API Access 🔐

What actually happens behind the scenes when you click “Sign in”?
I created this visual data-flow diagram to break down the complete journey:
User → Identity Provider → Authorization Code → PKCE → Tokens → API → Resource Server
If you're learning OAuth 2.0, OIDC, or API security, this diagram should make the flow much easier to understand.

Which part of the OAuth flow do you find most confusing?

OAuth2 #OpenIDConnect #SoftwareEngineering

What Actually Happens When You Index a Document in Elasticsearch?

anuj kumar — Fri, 09 Oct 2026 17:07:58 +0000

Let me know where you use it in your current or past projects , and what kind of challenges your faced?

What Actually Happens When You Search in Elasticsearch?

anuj kumar — Fri, 09 Oct 2026 17:05:35 +0000

Kafka vs NATS vs Kinesis: The Streaming Decision Map Engineers Wish They Had Before Production.

anuj kumar — Fri, 09 Oct 2026 17:02:14 +0000

Kafka vs NATS vs Kinesis: The Streaming Decision Map Engineers Wish They Had Before Production.
Let me know which one you use and what kind of challenges you face with these systems in your day-to-day operations.

I have experienced that Kinesis Stream read/write limit is shared across all consumers unless you opt for premium feature EFO( enhanced fan out) is sound like a constraint but I have seen it working just fine for 67 millions events per day as that limit is per shard and best part is that is is serverless so no need to worry for any infra or scaling issues during season peaks.

🚀 Zero-Downtime Database Schema Migration: How to Evolve Without Breaking Production

anuj kumar — Fri, 09 Oct 2026 16:58:13 +0000

🚀 Zero-Downtime Database Schema Migration: How to Evolve Without Breaking Production
Situation
A live Spring Boot service depended on an Oracle RDS schema that required a major redesign, new tables, new columns, changed relationships, and migrated data while existing consumers still needed uninterrupted access.
Task
Introduce the new schema and application version with zero downtime, while preserving backward compatibility and maintaining a safe rollback path.
Action
I would use an Expand → Migrate → Switch → Contract approach:
• Expand the database with the new schema without breaking the old one
• Deploy a bridge version supporting both models
• Dual-write to old and new structures
• Backfill and reconcile historical data
• Canary-release the new Spring Boot version
• Gradually switch reads to the new schema
• Keep the legacy model available during the rollback window
• Retire old tables only after production stability is proven
Result
The architecture enables schema evolution with no consumer downtime, controlled migration risk, progressive validation, and rapid rollback capability.
The key lesson:
👉 Never make the database incompatible with the application version currently serving production traffic.
The diagram below visualises the complete migration journey from legacy schema to the new model.

SoftwareArchitecture #SystemDesign #SpringBoot #Java #AWS #Oracle #DatabaseMigration #ZeroDowntime #Microservices #CloudArchitecture #SolutionArchitecture

The Outbox Pattern isn't really about messaging. It's about eliminating an impossible atomicity assumption

anuj kumar — Fri, 09 Oct 2026 16:56:39 +0000

The Outbox Pattern isn't really about messaging. It's about eliminating an impossible atomicity assumption: “I'll update my database and then publish the event.” This visual shows what actually happens when failure occurs between those two operations, and why idempotency is still required.

The invariant is a committed business change must not become disconnected from the event describing that change. The application therefore commits the business record and outbox record in one local transaction; a relay or CDC process publishes the committed outbox event asynchronously. This is a solution to the distributed-system dual-write problem.

The subtle point is that Outbox does not magically create exactly-once processing. Publication can still be retried and consumers should remain idempotent.

Use unique event ID for deduplication and uses the aggregate ID as the event key, which matters for preserving aggregate ordering in Kafka partitions.

At 10× scale, the interesting bottleneck frequently moves from the broker to the outbox table and publisher: polling frequency, indexes, cleanup, CDC lag, payload size and partition-key distribution become architecture concerns.

CAP Theorem finally clicked for me when I stopped thinking “pick 2 out of 3.”

anuj kumar — Fri, 09 Oct 2026 16:46:00 +0000

Imagine an eCommerce platform running across US and EU regions.
There is 1 item left.
Two customers try to buy it.
Then the network between the regions fails.
Now the architecture has a decision to make:
🟢 Protect Consistency

If the region cannot establish the authority required to reserve that inventory, wait or reject the operation rather than risk selling the same unit twice.
🟠 Protect Availability

For something like a product catalog or parcel-tracking read model, continue serving local data even if it may temporarily be stale, then reconcile when connectivity returns.
The important lesson:
Partition tolerance isn't really the choice in a multi-region system. Network partitions will happen.
The architectural question becomes:
When communication fails, which guarantee matters more for this specific operation — consistency or availability?
And one subtle point that is often missed:
CAP does not decide whether US or EU “wins.”
That comes from your ownership model, quorum/consensus mechanism, routing strategy, or business rules.
This is also why I wouldn't simply label an architecture with stateless application servers and one database as “CA.” CAP becomes operationally interesting when distributed copies of state can no longer reliably coordinate.
For architects, the better question isn't:
“Is my system CP or AP?”
It is:
“Which business invariant am I protecting during a partition, and what am I prepared to sacrifice to protect it?”

SoftwareArchitecture #DistributedSystems #CAPTheorem #SystemDesign #Microservices #AWS #Java #CloudArchitecture #TechnicalArchitecture

Retries + Backoff + Jitter: How a Small Failure Becomes a Retry Storm.

anuj kumar — Fri, 09 Oct 2026 16:29:34 +0000

Retries + Backoff + Jitter: How a Small Failure Becomes a Retry Storm.

Retries improve availability until they become the outage. The dangerous question isn't How many retries should we configure? It's which layer owns the retry, is the operation idempotent, and what happens when 10,000 clients retry together?

The key mental model is a retry consumes additional capacity from the system that may already be failing. AWS's Builders' Library gives a particularly memorable example: with a five-deep service stack and three retries independently occurring at each layer, load against the database can increase 243×
Backoff alone isn't enough. Correlated clients can wake up together and generate another burst, which is why jitter spreads retry arrival times.

The other architect-level subtlety is timeout ambiguity. A timeout tells the caller that it didn't receive a successful response; it doesn't prove the remote operation didn't happen. Side-effecting operations such as payment creation, order submission or label purchase therefore need idempotency semantics before automatic retries are safe.

I hope below visual model helps to understand it better. Let me what kind of issues you faced with retried in in which layer, and do you track it?

🚀Stop letting your monitoring agents slow down your production traffic!

anuj kumar — Fri, 09 Oct 2026 16:21:54 +0000

Ever wondered if tracking metrics, traces, and logs (MELT: Metrics, Events, Logs, and Traces) impacts your application performance during massive peak loads?

The magic lies in Asynchronous OTLP( Open Telemetry Protocol) Execution.

When a user hits "Checkout" in a high-volume Spring Boot eCommerce app, the application doesn't wait for your monitoring tools to say "received". Instead, it hands the telemetry data to a lightning-fast, non-blocking in-memory queue and instantly responds to the customer.

Background daemon threads handle the heavy lifting—compressing, batching, and shipping those records to platforms like Splunk AppDynamics or Prometheus over gRPC. And if the backend fails under heavy load? Built-in memory boundaries intentionally drop telemetry data rather than allowing a monitoring bottleneck to crash your production database.

Check out this data flow layout showing how modern OpenTelemetry architecture separates the synchronous user path from asynchronous telemetry shipping! 🌟

OpenTelemetry #SpringBoot #Java #AppDynamics #Architecture #DevOps #Observability #CloudNative #APM