DEV Community: AIshwarya Kumar

The Cryptographic Pivot: From Symmetric to Asymmetric Efficiency

AIshwarya Kumar — Fri, 30 Jan 2026 16:12:54 +0000

In software architecture, security is often a trade-off between computational overhead and trust. To build secure systems, engineers must understand the symbiotic relationship between symmetric and asymmetric encryption. Neither is a "silver bullet"; rather, they are two distinct tools used to solve the fundamental problem of secure key distribution.

1. Symmetric Encryption: The Speed Demon

Symmetric encryption is the workhorse of data security. In this model, a single secret key is used for both the encryption of plaintext and the decryption of ciphertext. Modern algorithms like AES-256 (Advanced Encryption Standard) are the industry standard here.

The Advantages:

Performance: Symmetric encryption is computationally "cheap." It relies on bitwise operations and substitutions that can be executed at the hardware level with minimal latency.

Throughput: It is ideal for encrypting large volumes of data, such as database volumes, file systems, or streaming media.

The Challenge: The Key Distribution Problem The fatal flaw of symmetric encryption is not the algorithm itself, but the logistics. For two parties to communicate, they must both possess the secret key. If they are communicating over an untrusted network (like the internet), how do they share that key without an eavesdropper intercepting it? If you can't securely share the key, you can't securely share the data.

2. Asymmetric Encryption: The Infrastructure of Trust

Asymmetric encryption (or Public-Key Cryptography) solves the distribution problem by using a mathematically linked Key Pair: a Public Key and a Private Key.

In this architecture, the Public Key can be distributed openly. Anyone can use it to encrypt data, but that data can only be decrypted by the corresponding Private Key, which remains strictly confidential with the owner.

How it Fixes Symmetric Encryption: Asymmetric encryption allows two parties to establish a secure channel without ever having shared a secret beforehand. A client can simply ask for a server’s Public Key, encrypt a message, and know that only that specific server can read it.

The Catch: Asymmetric encryption is mathematically intensive. It relies on complex number theory (like prime factorization in RSA or elliptic curve pairings in ECC). Using it to encrypt a 10GB file would be orders of magnitude slower than symmetric encryption and would place an immense burden on the CPU.

3. The Hybrid Solution: Real-World Implementation (TLS)

In professional software engineering, we rarely choose one over the other. Instead, we use a Hybrid Cryptosystem. The most ubiquitous example of this is the SSL/TLS Handshake used in HTTPS.

The Workflow

Asymmetric for the Handshake (Key Exchange): The browser uses the server’s Public Key to securely send a piece of "pre-master" secret data. Because this is a small amount of data, the computational cost of asymmetric encryption is negligible.

The Pivot: Both the browser and the server use that shared secret to derive a Symmetric Session Key.

Symmetric for the Session (Data Transfer): For the remainder of the connection, all application data (HTML, JSON, images) is encrypted using the Symmetric Key. This ensures the speed remains high while the initial "hand-off" remains secure.

Summary

Use Symmetric (AES) when you need to encrypt data-at-rest or high-volume data-in-transit where both parties already share a secret.

Use Asymmetric (RSA/ECC) for identity verification (Digital Signatures) and for the initial secure exchange of symmetric keys.

The Hybrid Approach is the gold standard, leveraging asymmetric encryption for Key Exchange and symmetric encryption for Bulk Encryption.

Coroutines for a 5 year old

AIshwarya Kumar — Mon, 26 Jan 2026 08:52:51 +0000

Assuming the 5 year old already knows Threads ;-)

A coroutine is an instance of suspendable computation. It is conceptually similar to a thread, in the sense that it takes a block of code to run that works concurrently with the rest of the code. However, a coroutine is not bound to any particular thread. It may suspend its execution in one thread and resume in another one.

That was from https://kotlinlang.org/docs/coroutines-basics.html#your-first-coroutine

Let’s translate that.

There is a long street with banks, offices, shops, restaurants, schools along the way. You and your neighbors and friends and family's and perfect strangers, all of you living at that street have a job.

Now you start from home and take a Taxi. Midway, you have to stop at the bank to draw some cash. You hop off the taxi, because you don’t want to keep it waiting. Taxi is now free to give a ride to some one else with a job.

Once you are finished with your work in bank, you come out, wave at another Taxi that was waiting nearby and move along.

You all are Coroutines. Taxis are Threads.

Unicode, UCS & UTF-8

AIshwarya Kumar — Mon, 26 Jan 2026 08:47:27 +0000

Unicode is a standard that defines, along with ISO/IEC 10646, Universal Character Set (UCS) which is a superset of all existing characters required to represent practically all known languages.

Unicode assigns a Name and a Number (Character Code, or Code-Point) to each character in its repertoire.

UTF-8 encoding, is a way to represent these characters digitally in computer memory. UTF-8 maps each code-point into a sequence of octets (8-bit bytes)

Become a member
For e.g.,

UCS Character = Unicode Han Character

UCS code-point = U+24B62

UTF-8 encoding
(in hex) = F0 A4 AD A2
(in binary) = 11110000 10100100 10101101 10100010

Logging Without the Noise: A Tiered Strategy for Clean Architecture

AIshwarya Kumar — Mon, 26 Jan 2026 08:33:21 +0000

In the heat of development, logging is often the first thing we add and the last thing we standardize. We’ve all been there: staring at a production log stream where a single network glitch has triggered fifteen identical error messages across five different layers—or worse, a silent failure where the logs say absolutely nothing at all.

Effective logging is more than just a print statement with a timestamp; it is a semantic contract between your code and your future self. When logs are treated as an afterthought, they quickly devolve into "log pollution," where critical signals are buried under a mountain of DEBUG spam and duplicate stack traces.

To maintain a truly "Clean Architecture," we must treat logging with the same rigor as our business logic. This means defining clear ownership for every log entry and ensuring that errors move outward while logging happens only once. This guide outlines the formal rules of engagement for logging across different architectural layers, ensuring your logs provide high-fidelity diagnostic data without the deafening noise.

Why This Matters:

Searchability: Standardized logs mean faster debugging during outages.

Security: Explicit "What NOT to log" rules prevent PII (Personally Identifiable Information) leaks.

Clarity: By logging only at the "final call site," you eliminate the confusion caused by redundant error reports.

Layer	Responsibility	What to Log	What NOT to Log	Log Level
UI / Compose	Show user-friendly errors. No technical logging unless for debugging UI state.	Optional `Log.d()` for UI actions when debugging.	Stack traces, backend details, sensitive user data.	`DEBUG` (optional)
ViewModel	Final call site for logging. Catches exceptions from repository/use-case layer and logs them once.	Operation context, exception type, stack trace (unless known/handled case), safe identifiers.	Sensitive data, raw server responses.	`ERROR` or `WARN`
Use Case / Interactor	Translate repository errors into domain errors, propagate upwards. No logging unless critical business rule failed.	Only critical domain-specific failures if unrecoverable at higher levels.	All transient/expected exceptions (network blips, retries).	`ERROR` (rare)
Repository	Catch low-level exceptions, wrap into domain-specific errors, propagate upwards. No logging.	Nothing by default.	Everything (logging here will cause duplication).	None
Data Source (API, DB)	Throw exceptions up (wrapped if needed). No logging.	Nothing by default.	Same as repository — don’t log here.	None
Library Modules	Provide results or throw exceptions. Let caller log.	Nothing except optional internal `DEBUG` logs in dev builds.	Any production-facing logs.	`DEBUG` only (optional)

🔥 Core Thumb Rules

Log once, where handled
- The ViewModel (or final business logic handler) is typically the final call site.
Don’t log transient expected errors (like network timeouts if you retry automatically).
Keep logs developer-focused
- Technical detail + stack trace for devs, friendly plain language for users.
Preserve cause when throwing
- throw MyAppException("message", cause) so the final log still has the original stack trace.
Never log sensitive data
- Access tokens, passwords, personal identifiers.
Use log levels meaningfully
- DEBUG → Dev only
- INFO → Rare, key events only
- WARN → Recoverable problem
- ERROR → Needs investigation

📌 Example Flow

Library → throws DownloadException
Repository → catches, wraps into NetworkError.DownloadFailed, rethrows
ViewModel → catches NetworkError.DownloadFailed, logs stack trace once, updates UI state
UI → shows “Could not fetch file. Please try again.”

A Structured Backend Architecture for Long-Lived Systems

AIshwarya Kumar — Mon, 26 Jan 2026 08:27:01 +0000

Formalizing Responsibility, Models, and Validation Boundaries

1. Problem Statement: Why Naïve Layering Fails at Scale

Most backend architectures begin with good intentions and degrade through incremental compromise. Controllers accumulate business logic “temporarily.” DTOs are reused internally “for convenience.” Repositories enforce rules “because the data is already there.” Over time, responsibility boundaries collapse, and the system becomes difficult to reason about without full-context knowledge.

The failure mode is not the absence of layers, but the absence of clear ownership. Naïve layering treats components as technical tiers rather than as semantic roles. As a result, business meaning becomes smeared across controllers, services, repositories, and database constraints, making correctness emergent rather than explicit.

This document formalizes an architecture whose primary goal is preserving semantic clarity under growth. The system is designed such that each layer answers a distinct question, each model has a single reason to exist, and each validation rule has a clearly defined owner.

2. Model Taxonomy and Responsibility Boundaries

This architecture distinguishes four categories of models, each corresponding to a different concern and lifecycle.

2.1 HTTP Request/Response DTOs (Transport Envelopes)

HTTP DTOs describe API shape, not business data. They exist to stabilize external contracts, support versioning, and group payloads. They are transport artifacts and intentionally disposable.

They may contain metadata, nesting, or naming that is irrelevant to the application core. They are not reused outside controllers.

2.2 Application Entities (Service-Level Data Contracts)

Application entities represent use-case input and output, independent of transport and persistence. They define what an application service consumes and produces.

They are:

Transport-agnostic
Domain-agnostic
Persistence-agnostic

They exist to decouple application logic from both HTTP and domain internals, enabling service reuse across transports and API evolution without service churn.

2.3 Rich Domain Models (Behavior + Invariants)

Domain models represent business truth. They own identity, invariants, and state transitions. They are internal to the application core and are never serialized directly or exposed externally.

They cannot exist in an invalid state and cannot be partially constructed. They are behavioral objects, not data structures.

2.4 Persistence Entities (Database Rows)

Persistence entities exist solely to match database schemas. They encode storage concerns such as column naming, normalization, and constraint representation. They have no behavior and no business meaning.

3. Controller Layer: Transport Adaptation, Not Logic

Controllers are transport adapters. They translate HTTP requests into application-level inputs and translate application outputs into HTTP responses.

Their responsibilities are limited to:

Parsing HTTP requests
Validating request shape and format
Constructing request DTOs
Extracting application entities
Mapping application entities to response DTOs

Controllers do not enforce business rules, perform persistence, or coordinate use cases. They are intentionally thin to ensure that changes in transport or API shape do not propagate into the application core.

Controllers are the only layer that understands HTTP semantics.

4. Application Services as Use-Case Orchestrators

Application services represent intent. Each service corresponds to a single use case and expresses what the system is trying to accomplish, not how data is stored or transported.

Services:

Consume application entities
Load required aggregates
Enforce business rules that require coordination or persistence knowledge
Create and mutate domain models
Decide when persistence occurs
Return Rich Domain Models and/or Domain-derived projections

Services are the only layer where domain objects are created. This ensures that aggregates always come into existence through a valid use case rather than through incidental construction.

Services derive meaning from facts. They do not store data, and they do not encode transport or persistence concerns.

5. Rich Domain Models as the Source of Truth

The domain layer is the semantic core of the system. It encodes what is always true regardless of use case, transport, or persistence.

Domain models:

Own identity
Own invariants
Own consistency rules
Encapsulate state transitions
Are persistence-agnostic

Invariants that can be enforced with local aggregate knowledge belong here. If a rule can be expressed without querying external state, it is a domain concern.

Domain models expose their state only through controlled methods and, when required, through defensive copies (toData) to prevent external mutation.

6. Repositories as Persistence Adapters

Repositories are infrastructure adapters that translate between domain snapshots and persistence representations.

Repositories:

Accept fully valid domain snapshots
Convert domain data to persistence entities
Persist atomically
Rehydrate domain models from stored data
Enforce persistence-level constraints only

They do not generate identity, enforce business rules, or derive meaning. If removing a rule from a repository would change product behavior, that rule does not belong there.

Repositories return facts, not interpretations.

7. Identity, Immutability, and Aggregate Boundaries

Identity is generated by the domain, not by the database. Aggregates must exist conceptually before persistence, enabling offline creation, deterministic testing, and distributed workflows.

Immutability is enforced at the aggregate boundary, not through pervasive readonly fields. Internal state is private; external access is mediated through behavior or defensive copies. This ensures invariants remain protected while allowing efficient internal mutation.

Aggregate boundaries define consistency scopes. Only data owned by the aggregate is directly mutated; external relationships are coordinated at the service level.

8. Validation Flow and Error Propagation

Validation is layered and directional.

Controllers validate shape and format
Services validate meaning and cross-aggregate rules
Domain models enforce invariants
Databases enforce constraints

Errors propagate outward. No layer catches and reinterprets errors from a deeper layer into its own semantic domain. Controllers alone translate errors into HTTP responses.

This ensures that invalid operations fail early, partial state is never persisted, and error semantics remain consistent.

9. Transactionality, Concurrency, and Reality

The architecture assumes optimistic concurrency. Lost updates are acceptable until the business requires stronger guarantees. Transactions are used for atomicity, not for semantic correctness.

Stricter guarantees — versioning, compare-and-swap, or locking — are introduced only when demanded by business rules. Concurrency control is treated as an explicit design decision, not an implicit side effect of database usage.

10. End-to-End Request Lifecycle

Forward Path

HTTP JSON → Controller → Request DTO → Application Entity → Service → Domain Model → Repository → Database Row

Backward Path

Database Row → Repository → Domain Model → Service → Application Entity → Controller → Response DTO → HTTP JSON

Every transformation is intentional. No layer is skipped. No responsibility is shared.

11. Error Propagation Rule (Critical)

Errors move outward, never inward

That is the invariant of the architecture.

Controllers are the only place where errors become HTTP responses.

Controllers validate shape
Services validate meaning
Domains protect truth
Databases enforce reality

Error Propagation Rule (Critical)

12. Trade-offs and Explicit Non-Goals

This architecture favors clarity over minimalism. It introduces additional model types and explicit mapping steps, increasing upfront structure.

It does not optimize for:

Rapid prototyping with minimal abstraction
Active Record patterns
Framework-driven convenience
Implicit persistence behavior

These are conscious exclusions.

13. Why This Architecture Remains Evolvable

The system remains evolvable because responsibilities are stable even as implementations change. APIs can evolve without touching services. Persistence can change without affecting domain logic. Domain rules can grow without leaking into transport or storage.

Most importantly, correctness remains local. Engineers can reason about changes by understanding a single layer at a time rather than reconstructing global behavior.

This architecture does not eliminate complexity. It contains it.

The Architect’s Dilemma: Finding the “Middle Way” Between Lean Lists and Rich Truths

AIshwarya Kumar — Mon, 26 Jan 2026 08:20:19 +0000

Designing List APIs That Do Not Lie

List APIs are deceptively simple.

They are also the most common source of long-term architectural decay.

In content-heavy systems — such as note-taking applications — lists dominate user interaction: recent notes, search results, pinned notes, category views. Yet these same systems routinely treat list APIs as an afterthought, implementing them as a trivial extension of CRUD.

This article documents a mature design approach to list APIs, grounded in real-world failure modes and corrected through explicit architectural constraints. While the examples use a note-taking application, the principles apply equally to documents, tasks, tickets, messages, or any domain with large entities and relational context.

1. The Fundamental Mistake: Treating Lists as Collections of Entities

A note in a production system is rarely small. It may contain:

thousands of words of body content
structured blocks or rich formatting
attachments and embedded media
backlinks and references
tags, categories, notebooks
collaboration metadata and history

A list of notes, however, typically needs only:

identifier
title
preview or excerpt
last-updated timestamp
relationship identifiers (tags, category)

Treating a list as “an array of full notes” conflates two different use-cases:

- Entity access (detail, edit, export)

- List rendering (browse, search, navigate)

This conflation leads to three systemic problems.

Payload Bloat — Every list response carries large fields that are never rendered.
Cache Churn — Editing one note invalidates list caches unnecessarily because list and detail share the same shape.
Semantic Drift — Frontend code begins to assume detail-only fields exist in list contexts, creating fragile UI behavior.

The root issue is not performance — it is dishonest contracts.

2. Entity vs Projection: Separating Truth from Use-Case

The first corrective step is conceptual clarity.

The Entity

A NoteEntity represents the complete, authoritative truth of a note. It is expensive and comprehensive by design.

The Projection

A NoteListItemEntity is a projection: a purpose-built representation for list use-cases. It is intentionally incomplete.

The API contract becomes explicit:

GET /api/notes → returns NoteListItemEntity[]

GET /api/notes/:id → returns NoteEntity

This separation is not an optimization — it is semantic alignment.

Lists are not “partial entities.”

They are different representations with different guarantees.

3. Related Data: Embed, Side-Load, or Resolve Contextually

Notes reference related data such as tags and categories. List APIs must handle this deliberately.

What Not to Do: Embed Per Row

Embedding full tag or category objects inside every list item causes duplication, payload inflation, and unstable caches.

The Side-Loading Pattern

Instead, list APIs return a standard envelope:

{

“items”: […],

“sideLoads”: {

“tagsById”: { … },

“categoriesById”: { … }

}

}

This achieves:

zero duplication
stable payloads
efficient resolution of display data

Contextual Resolution

In some systems, related data may already exist in shared caches (e.g., category trees). In such cases, side-loading can be omitted entirely.

The rule is simple:

Relationships must be intentional, not incidental.

4. The Frontend Problem: Summary Objects That Look Complete

Once projections exist, a new class of bugs appears.

A developer writes:

note.bodyText

on a list item.

Most systems return undefined.

The UI breaks subtly. The bug surfaces later. The cause is unclear.

This is worse than a crash.

5. Rich Frontend Domain Models

The frontend must not operate on raw transport shapes.

Instead, it introduces a domain model:

- Note.fromEntity() → full note

- Note.fromListItemEntity() → summary note

Both return the same domain type, but with different guarantees.

This enables consistent UI code while preserving correctness.

6. Runtime Guards: Failing Fast Instead of Failing Silently

The system must refuse misuse, not tolerate it.

If a developer accesses a detail-only field on a summary note, the model throws:

Note.bodyText is not available on a summary Note. Fetch full details before accessing this field.

This is deliberate.

It fails immediately
It explains the violation
It points to the correct fix

Runtime guards convert silent UI corruption into explicit architectural errors.

This is not defensive programming — it is semantic enforcement.

7. Provenance, Not Data, Determines Completeness

A critical nuance: completeness must not be inferred from data presence.

A full note may legitimately have empty content, empty metadata, or empty relationships.

Therefore, the system must encode provenance explicitly:

constructed from list projection → summary
constructed from detail entity → full

Completeness is about origin, not content.

Both runtime guards and UI orchestration depend on this invariant.

8. Stable Pagination Is Part of the Contract

List APIs must provide deterministic behavior.

Why Offset Pagination Fails

Offset-based pagination assumes immutability. Production datasets are mutable.

Insertions and deletions cause:

duplicates
missing items
inconsistent ordering

Enterprise-Grade Invariants

Cursor-based pagination
Explicit primary sorting (e.g. updatedAt)
Explicit secondary sorting (e.g. id)
Sorting fields must exist in the projection

Pagination and sorting are API contracts, not UI conveniences.

9. The Transformation Tax

This architecture introduces overhead:

additional types
mapping logic
explicit contracts
guard logic

This is the Transformation Tax. And it is better than accumulating Technical debt.

It is paid once, intentionally, rather than continuously through:

performance regressions
cache invalidation bugs
UI instability
accidental coupling

In long-lived systems, discipline is cheaper than convenience.

Closing Perspective

List APIs are not trivial endpoints.

They are the most frequently exercised contracts in a system.

A list is not an entity.

A summary is not an incomplete truth.

And silence is not safety.

Well-designed list APIs tell the truth — and enforce it.

That is the difference between software that merely works and systems that endure.

Clean Architecture

AIshwarya Kumar — Mon, 26 Jan 2026 08:15:20 +0000

Clean Architecture, as formalized by Robert C. Martin, is a software design philosophy prioritized by the Dependency Rule: source code dependencies must only point inwards, toward higher-level policies.

At its structural core, Clean Architecture is an exercise in dependency management. It transforms the traditional “top-down” dependency model — where business logic depends on specific databases or UI frameworks — into a model where the core logic is entirely autonomous.

This treatise examines the formal constraints of Clean Architecture, a software design paradigm that prioritizes the decoupling of high-level business logic from low-level implementation details. We analyze the architecture through two primary lenses: the Dependency Rule (governing directional flow) and the Inversion of Control (governing interface ownership). By adhering to these constraints, a system achieves “Independence of Mechanism,” allowing the core policy to remain agnostic of its delivery environment.

1. The Dependency Rule: A Constraint on Directionality

The fundamental axiom of Clean Architecture is the Dependency Rule. In a multi-layered system organized concentrically, the Rule states that source code dependencies must only point toward higher-level policies.

In formal terms, if we define a set of layers L = {L1, L2, …, Ln} where L1 represents the most abstract core (Entities) and Ln represents the most concrete periphery (Frameworks), any dependency D originating in Li must target a layer Lj such that j < i.

Impact on Compilation: This ensures that the core domain logic (L1) can be compiled and validated without the existence of the database or web server (Ln).
Stability vs. Volatility: Inner layers are characterized by high stability (low frequency of change), while outer layers are volatile. The Dependency Rule protects the stable core from the instability of its surroundings.

2. Interface Sovereignty and Dependency Inversion

The second core principle involves the strategic placement of interfaces to maintain the Dependency Rule during runtime execution. In traditional architectures, a business service might call a database driver directly, creating an outward-pointing dependency. Clean Architecture resolves this through the Dependency Inversion Principle (DIP).

2.1 The Concept of Interface Ownership

A common misconception is that interfaces belong to the implementation layer. In this paradigm, the inner layer owns the interface. If the Use Case layer requires data persistence, it defines an interface (e.g., IOrderRepository) within its own boundary.

2.2 Formal Logic of Inversion

Let P represent a high-level Policy and M represent a low-level Mechanism. To allow P to utilize M without depending on it, we introduce an Abstraction A such that:

P → A ← M

Here, P maintains a reference to A (which is situated within the same layer as P). M, residing in an outer layer, implements A. Consequently, at runtime, the flow of control moves from P to M, but the source code dependency remains strictly M → P.

3. End-to-End Execution Flow: A Scholarly Walkthrough

To illustrate these principles in situ, we observe the execution of a system command, such as “Process Payment.”

Phase I: Boundary Ingress

The execution begins at the Framework Layer. An external actor (e.g., a client via HTTP) provides a raw data structure. An Interface Adapter (the Controller) intercepts this data.6 To cross the boundary into the inner circle, the Controller maps the raw data into a Request Model — a simple, flat data structure defined by the Use Case layer.

Phase II: Application Orchestration

The Use Case Interactor receives the Request Model via an Input Boundary (Interface). The Interactor serves as the orchestrator. It directs the state transitions of Entities (the Enterprise-wide business rules). During this phase, if the Interactor requires external services (e.g., a database query or an external API call), it invokes an Output Boundary interface.

Phase III: Boundary Egress and Inversion implementation

The implementation of the aforementioned Output Boundary resides back in the Interface Adapter or Framework layers. For instance, a SqlDatabaseAdapter fulfills the contract defined by the inner Use Case. The data is persisted, and the flow returns to the Interactor.

Phase IV: Response Normalization

Upon completion, the Interactor packages the result into a Response Model. This is passed to a Presenter, which transforms the business-centric data into a format suitable for the delivery mechanism (e.g., a ViewModel or a specific JSON schema).

4. Conclusion

The rigor of Clean Architecture is found not in the number of layers, but in the strictness of the boundaries. By ensuring that the inner layers remain oblivious to the outer implementation details, we create a system that is “Screaming” with its intent — where the folder structure reflects the business domain rather than the choice of framework. This architectural discipline yields a system that is fundamentally testable, maintainable, and resilient to the inevitable obsolescence of third-party technologies.