In this post I cover routing, a two-tier model strategy, form-only contact, build-time context, rate limiting, persona boundaries, and state and security.

The system is built as a directed graph. Every message is classified by intent, then routed to either a Q&A path or a programmatic contact flow.

1. Deterministic Routing: Why a Router?

I wanted two distinct behaviors. The bot should answer questions based on my experience or offer a clear path to contact me.

Mixing these into one giant prompt was possible, but messy and prone to hallucinated instructions. By using a router, the system stays simple: one step classifies the intent, and the next step runs a specialized task. This separation makes it easier to add rate limits, fallback logic, and a "chat unavailable" path without tangling the core logic.

2. The Multi-Tier Model Strategy

To optimize for both speed and cost, I use a two-tier model setup:

The classifier (fast and cheap): A model optimized for low-latency, single-token-style output handles the initial routing. It only needs to output one word: question or contact.

The responder (strong and capable): A model used for open-ended generation over a large context is only invoked for the answer node, where it has to combine my resume, projects, and blog posts into a coherent reply.

The fallback: If the fast model is down, the system falls back to the stronger model for classification but applies a stricter rate limit to protect my quota. If both fail, the UI directs the user to the standalone contact page.

To find the current node, click on “View logic”.

3. Form-Only Contact

At first I tried a conversational lead-gen flow, asking for a name, then an email, then a message. It was brittle. Short names or test messages often triggered a "topic switch" misclassification.

So, I switched back to a standard UI. When a user expresses contact intent, the chat input is disabled and a structured form is shown directly in the chat thread.

This takes away the back-and-forth of message and also maintains a UI that is familiar to the user during data collection.

Additionally, I added an "Ask something else" button dismisses the form and clears contact state. The server also appends a short prompt so that the user is informed of the switch.

This is helpful if the user wants to clarify something before messaging, changes their mind about contact. It also helps on the off-chance that the AI hallucinates. The user can bring the focus back.

4. RAG-Lite: Build-Time Context and Caching

I did not need a vector database for a portfolio since I don't have huge content. My knowledge model also provides an ample context window.

Instead I use a build-time blog cache:

• A script fetches my latest blog posts from my external CMS during the build.

• The result is stored as a local JSON file.

• The answer node reads this file at request time and injects it into the system prompt.

If the blog fetch fails at build time, the script keeps the previous cache or writes an empty list so the build still succeeds. That way there is no runtime dependency on my CMS, and context (links and titles) stays accurate and fast. The answer prompt is also structured into sections (work history, projects, skills, blog, hire/contact) so the model can focus on the relevant part and cite sources by name and link, and visitors can click through to a project or post.

Using a RAG context, also removes unnecessary latency.

5. Resilience: Layered Rate Limiting

To protect my free-tier quotas and limit spam, I use three layers of rate limiting:

• Standard chat limit: A cap on general Q&A requests.

• Fallback limit: A tighter cap when the stronger model is used for classification (e.g. when the fast model is down).

• Contact limit: A strict, per-identifier limit on form submissions to reduce email spam.

6. Persona Boundaries and Adversarial Questions

A portfolio bot needs a clear persona and explicit boundaries.

Out-of-bounds: The prompt defines the bot as representing me, a full stack developer. It only answers about my experience, projects, skills, blog, and hiring or contact. For anything else it politely declines and points to the contact form.

That keeps the bot on topic and avoids answering things I don’t want it to (e.g. medical or legal). Since scope lives in one place, it is easy to tighten or relax later.

Negative framing: For questions like "Why shouldn't I hire her?" the model is instructed not to repeat the negative framing. Instead it pivots to fit: it asks about tech stack or project needs or suggests a call to discuss.

7. State Management and Security

Persistence: Conversations are keyed by a unique identifier. State (message history, contact flags) lives in a server-side key-value store with a 24-hour TTL. When the user reopens the chat, the client fetches the thread by that identifier so history loads without storing it all in the browser. The server stays stateless and the client stays light.

Safety: Since the model outputs markdown, the client converts it to HTML and passes it through a strict sanitization layer. The sanitization layer only allows safe tags like <a>, <code>, and <strong>. Citations and links from the model become clickable without trusting raw HTML. This helps prevent XSS attacks.

Thanks for reading! Let me know what you liked. Is there anything that I could do differently? Have you implemented something similar?

Here is the detailed breakdown of my January.

✅ Published:

The Web Accessibility Series I spent a good chunk of January writing. I’m happy to share that one of my major works—a 3-part series on Web Accessibility —is now live. What started as a simple refresher on browser dev tools became a deeper dig into the engineering side of inclusion.

• Part 1: The Invisible Loss: Why Your Site is Losing 16% of Its Traffic at the Door

• Part 2: The Science of Sight: Colors, Fonts, and the IBM Standard

• Part 3: The Developer’s Audit for A11Y

🤖 Learning Log: Agentic AI (Overview)

I’ve started a new learning track this month focused on Agentic AI via IBM Learn.

• Current Status: January was all about the overview—understanding the high-level concepts of how agents differ from standard LLMs.

• The Plan: I’m still reading through the materials. Over February, I plan to finish the introduction part.

🧹 Housekeeping: Polishing the Archive Back in October 2025, I launched v0.5 of harshnahaswani.com. This month, I focused on cleaning up the content. I had some raw technical notes. I converted 9 of them into structured blog posts (excluding the 3 part A11Y series).

👀 Looking Forward to February I have some specific releases and posts lined up for next month:

1. ASCII Graphs Update: I’m working on the next release for ascii-graphs.vercel.app. Expect some new features soon.

2. Portfolio Update: Some accessibility fixes and newsletter signup integration

3. Design Deep Dive: I’m writing a "meta" blog post about the style selection for my portfolio—breaking down why I chose this specific aesthetic and the design decisions behind it.

4. More Learning: Continuing the Agentic AI deep dive.

5. Housekeeping: At least 2 more blogs from my technical notes.

I love feedback. I would really appreciate it if you drop a comment below or send me a mail!

Thanks for reading!

– Harshna

Here is how to audit your site for the traffic waiting to get in.

1. The "No-Mouse" Challenge: Keyboard Navigation

For users with mobility issues, tremors, or chronic pain, the mouse is a barrier. They rely on the Tab key or assistive switches.

• Visible Focus States: Never use outline: none; in your CSS without providing a high-contrast replacement. If a user tabs to a button, they need a "Focus Ring" to see where they are.

• Tab Traps: A common failure point in development is the modal or mobile menu. Ensure users don't get "stuck" inside a pop-up with no way to exit via keyboard.

• Logical Flow: Your tabindex should follow the visual path of the page. If the cursor jumps from the header to the footer and back to the sidebar, the site is functionally broken for keyboard users.

2. The Code Behind the Vision

Effective accessibility requires moving beyond the visual layer into the document structure.

• Aria-Labels for "Silent" Icons: If you have a button that is simply a "Magnifying Glass" icon, a screen reader will likely announce it as "Button, unlabelled." By adding aria-label="Search", you give that element a clear purpose. If the icon has no purpose, hide it with aria-hidden=”true”.

  • 

• Scalable Units (The rem Fix): While we discussed why text needs to scale in Part 2, the developer’s job is the math. Use rem for font sizes so that when a user changes their browser's root font size, your UI responds fluidly. Reference the Mozilla Accessibility Guidelines for best practices on building these responsive structures.

• Semantic HTML: Use <button> for actions and <a> for navigation. Using a <div> with an onClick event might look the same, but it is invisible to assistive technologies unless you manually add the necessary ARIA roles.

3. Your Professional Audit Toolkit

Stop guessing and start validating. Leverage these industry-standard tools to automate your workflow and catch essential accessibility errors instantly:

• WAVE Evaluation Tool: The gold standard for browser-based audits. It provides a visual overlay of your live site, flagging missing alt-text, contrast failures, and structural issues.

• BrowserStack WCAG Guide: An excellent resource for running guided manual tests to ensure your site meets specific compliance levels.

Check issue with WAVE

Tabbed navigation inspection with WAVE

4. The Pro Powerhouse: Firefox Accessibility Inspector

Firefox has arguably the most powerful built-in tool for accessibility testing. By right-clicking any element and selecting "Inspect Accessibility Properties," you can verify your work in real-time.

• The Tree View: See exactly what a screen reader "sees" before you ever publish your code.

• Color Blindness Simulation: Filter your live site through various lenses to ensure the colors hold up in production environments.

  • 

• Contrast Warnings: Firefox will automatically flag elements that fail the AA (4.5:1) or AAA (7:1) thresholds, highlighting the specific line of CSS that needs adjustment.

  

Conclusion: Opening the Door

Accessibility isn't a "one-and-done" checklist; it is a fundamental shift in how we build for the web. By mastering these tools—from the WAVE extension to the Firefox Inspector—you aren't just "fixing bugs." You are ensuring that the 16% of users who have been standing at the door can finally walk in.

The web was built to be universal. As developers, it is our job to make sure it stays that way.

This article was copyedited with Gemini.

Designing for the eyes isn’t just about aesthetics; it’s about math, clarity, and understanding the medical reality of how different people perceive light and color.

1. The Math of Contrast: AA vs. AAA

Most designers know that light gray text on a white background is a "trend," but for millions of users, that trend makes a website invisible. To solve this, the Web Content Accessibility Guidelines (WCAG) use contrast ratios.

• Level AA (The Standard): Requires a contrast ratio of at least 4.5:1 for normal text. This is the baseline to ensure users with moderate low vision can read your content.

• Level AAA (The Gold Standard): Requires a ratio of 7:1. This makes your site incredibly crisp for everyone and is essential for higher-level inclusivity.

2. The IBM Standard: Palette Engineering

You don't have to guess if your colors work. Tech giants like IBM have turned accessibility into a science through their Carbon Design System. They utilize a "Color Grade" system (ranging from 10 to 100) where the numerical "step" between two colors mathematically guarantees their accessibility.

• For Dark Backgrounds: Any color graded 60 or higher is safe to use with white text.

• For Light Backgrounds: Any color graded 50 or lower is safe to use with black text.

By adopting a palette that accounts for this non-text contrast, you ensure that "actionable" elements like buttons, icons, and input borders are just as visible and functional as your primary headlines.

3. Beyond Color: Why a "Single Highlight" Fails

Color blindness affects roughly 1 in 12 men and 1 in 200 women. If your website uses only color to convey meaning then, many users won't see the difference. Example, a red border for an error or a green highlight for a "success" state

According to official WCAG Use of Color standards, color should never be the only messenger.

The Rule: Always pair color with a secondary cue, such as an icon, a text label, or an underline.

In the above image, the blog section (right) has a indication of links with the right arrow while the project section(left) becomes ambiguous for a person who can’t distinguish color (in simpler terms, no color).

I also want to point out that this is from my own site, that had an update a few days ago. As people, it is very easy for us to miss things.

A few minutes of our time to check for accessibility can easily help us recognize and fix them.

🛠️ The Designer’s Testing Toolkit

Before you finalize a design, test your assumptions with these simulators:

• David Math Logic Palette Builder: Create a palette that is mathematically safe for color-blind users from the start.

• Coblis Simulator: Upload your mockups to see exactly how they appear to someone with different types of color vision deficiency.

• Jfly Color Palette: A master reference for a universal color set that is unambiguous to all.

4. Typography: More Than Just Style

A font can be "beautiful" but functionally broken. For users with dyslexia or low vision, certain typefaces are a maze.

Avoid Decorative and Cursive Fonts

While cursive looks "premium," it is a nightmare for accessibility for two reasons:

1. Character Ambiguity: Cursive fonts often have "ligatures" (where letters join together). Example, for users with Dyslexia, it becomes impossible to distinguish where an 'm' ends and an 'n' begins in the word Alumni.

2. OCR Failures: Screen readers often struggle to decode stylized characters, sometimes misreading them as symbols or skipping them entirely.

See the Distropiax font for example on the word "Alumni"":

• “l“ “u“ pair and “n“ “i“ pair is connected at the bottom seeming like a single letter

• “m“ and “n“ are very similar

• ”a” seems more like a symbol/logo than a letter

These things also increase cognitive load.

Research by University of Michigan, USA found that font types have an impact on readability of people with dyslexia. Good fonts for people with dyslexia are Helvetica, Courier, Arial, Verdana, and CMU.

The "No Images of Text" Rule

Never "bake" your text into a .jpg or .png file. It creates a technical dead end:

• Zero Scalability: When a user zooms in to 200%, a font rendered in CSS remains crisp. An image of text becomes a blurry, pixelated mess.

• The Alt-Text Trap: Alt-Text isn't a substitute for real text. Users cannot select, copy, or highlight text inside an image. If they need to copy a coupon code from an image, they are stuck. Reference: W3C definition on images of text.

See the below images, at 125% zoom, it reaches maximum width of the screen and the text can no longer increase in size. The letters in the image have lost their sharpness while the plain takes still remains sharp.

Use Scalable Units (rem over px)

Stop using pixels (px) for font sizes. Using rem allows your text to scale based on the user's browser settings. If a user needs 24pt font to see, your site should "listen" to that preference rather than locking them into your design choice.

In the image below, all components have smoothly scaled even at 400% zoom.

Fonts to avoid

• Low Contrast/Thin Strokes: Makes letters difficult to distinguish:

  • 

• Crowded Lettering: Letters are too close together, causing them to blend. Example: Serif fonts like Times New Roman

• Mirroring/Similarity: Letters that are too similar increase confusion. Example:

  • 'b', 'd',

  • 'p', 'q',

  • 'l' (lowercase L), 'I' (Capital I), '1' (number one)

5. The Browser "Stress Test"

You can perform a DIY audit using the built-in tools in Firefox or Safari. Open your site and try to:

• Increase the font size to 200%.

• Force a change to a basic system font.

• Check if your essential information remains readable.

If your layout overlaps or disappears, your design isn't truly accessible yet.

Coming Next: Part 3—The Developer’s Audit. We’ll get technical with the WAVE extension, BrowserStack, and the Firefox Accessibility Inspector.

This article was copyedited with Gemini.

In the physical world, you’d call a locksmith immediately. But in the digital world, thousands of businesses leave that door locked every day without realizing it.

The 16% Metric: It’s Not a Niche; It’s the Market

According to the World Health Organization (WHO), an estimated 1.3 billion people (1 in 6 people worldwide) experience a significant disability. That is 16% of the global population.

When we talk about "web accessibility," we aren't just talking about a minor technical adjustment. We are talking about serving:

• Visual Impairments: From total blindness to age-related low vision.

• Motor Disabilities: Users who cannot use a mouse and rely entirely on keyboards or switches.

• Cognitive Differences: Users with dyslexia, ADHD, or processing disorders.

If your website isn't accessible, you are effectively turning away 16% of your potential revenue. In the UK alone, this "Purple Pound" (the spending power of disabled households) is worth an estimated £274 billion. Can your business afford to leave that on the table?

The "Curb Cut" Effect: Better for One, Better for All

Accessibility is often misunderstood as something we do only for a specific group. In reality, accessible design makes the web better for everyone. This is known as the Curb Cut Effect.

Curb cuts (the slopes in sidewalks) were originally designed for wheelchair users. Today, they are used by parents with strollers, travelers with suitcases, and delivery workers with dollies. On your website, this looks like:

Understanding the Ladder: AA vs. AAA

To keep the web consistent, we use the WCAG (Web Content Accessibility Guidelines). Think of these as the building codes for the internet. They are broken into three levels of compliance:

The "Silent Door" is Real

In this three-part series, we are going to look at the tools and techniques required to unlock your digital door. We’ll explore how companies like IBM use math to pick accessible colors and how you can use simple browser tools to see your site through your users' eyes.

For today, your only task is to acknowledge the data. Your "missing 16%" is waiting to get in. Are you ready to unlock the door?

Coming Next: Part 2—The Science of Sight. We dive into color contrast math, the IBM Carbon palette, and why your font choice might be pushing readers away.

This article was copyedited with Gemini.

Wikipedia hosts over 65 million articles.

When you type "Virat Kohli" into the search bar, the system has to scan that massive dataset, handle typos, rank results by relevance, and deliver the answer in milliseconds.

If you tried this with a standard SQL database query (LIKE %Virat%), it would trigger a Full Table Scan—reading every single row. At Wikipedia’s scale, that would take seconds or even timeout.

Hence, they use Elasticsearch.

Here is the engineering logic behind that speed, broken down into 4 steps.

1. The Data: Documents, Not Tables

Relational databases split data across multiple tables to reduce redundancy. Elasticsearch optimizes strictly for retrieval speed.

It stores data as denormalized JSON Documents. Here is what the document for "Virat Kohli" looks like in our index:

 {
  "title": "Virat Kohli",
  "description": "Indian cricketer (born 1988)",
  "content_urls": {
    "desktop": { "page": "https://en.wikipedia.org/wiki/Virat_Kohli" }
  },
  "extract": "Virat Kohli is an Indian international cricketer..."
}

By keeping the data together in one object, we avoid expensive JOIN operations during the search.

2. Analysis: Breaking Down the Input

When we save this document, Elasticsearch runs it through an Analysis Pipeline. The goal is to convert raw text into searchable tokens.

For example, if the input is "Virat Parvam", the engine performs two key steps:

1. Lowercase: "Virat Parvam" to "virat parvam"

2. Tokenize: Split by whitespace: ["virat", "parvam"]

The engine indexes these specific tokens, not the raw sentence. This is why a search for "virat" (lowercase) will still match "Virat" (uppercase).

3. The Index: The "Back of the Book"

This is the secret sauce. Instead of scanning every document (like SQL), Elasticsearch uses an Inverted Index.

Think of it like the index at the back of a textbook. It lists every unique word and the exact Document IDs where that word appears.

Here is a simplified view of the index for our dataset:

When you search for "Virat":

The engine jumps straight to "V" in the index. It finds "Virat".
It instantly retrieves the list: [doc1859, doc8834].

This changes the time complexity from O(N) (linear scan) to O(1) (instant lookup).

4. Ranking: It’s Not Just "Found", It’s "Best"

We found multiple documents containing "Virat". But which one is first?

• The article titled "Virat Kohli" and a list of centuries by Virat Kohli

• An author who wrote a book about him

• Cartoon roughly based on Virat Kohli

• Similar name

  

Elasticsearch assigns a Relevance Score to every result (using the BM25 algorithm). It calculates this based on three main factors:

1. Term Frequency (TF): How often does the word appear in the document? If a document mentions "Virat" 10 times, it is likely more relevant than a document that mentions him once.

2. Inverse Document Frequency (IDF): How rare is the word? Common words like "the" have a low score. Rare words like "Virat" have a high score.

3. Custom boosting logic: E.g. A match in the Title field is often weighted as more important than a match in the Body field.

Consider that the following criteria is used to assign points

• Virat: 0.25 (term match in title)

• Kohli: 0.5 (Rare term match in title)

• Virat in description: 0.20

• Kohli in description: 0.45

• Exact query match: 0.2

Here is how our results might be scored:

1. Virat Kohli (Exact Match + High Field Boost): Score 0.95

2. List of Centuries... (High Term Frequency): Score 0.75

3. Virat in description (Low Term Frequency): Score 0.20

Summary

The shift from SQL to Elasticsearch isn’t just about changing databases; it’s about changing your mindset. We move from asking "How do I save space?" to "How do I find this instantly?" This retrieval-first approach relies on four key architectural pillars:

1. ​ Ingestion: Storing data as JSON documents.

2. ​ Analysis: Tokenizing text into searchable terms.

3. ​ Indexing: Using an Inverted Index for O(1) lookups.

4. ​ Ranking: Scoring results by relevance.

This is a perfect example of how choosing the right data structure(Inverted Index) solves scalability problems that raw computing power cannot.

I use Elasticsearch in production daily. I wrote this article to solidify the fundamentals and visualize the mechanics. If you’re working on similar search scaling challenges, feel free to reach out!

Note: This article was drafted with the assistance of Google Gemini to refine the technical explanations and structure.

Ever wondered how a simple tap on your favourite delivery app translates to hot food at your door? The instantaneous experience hides a sophisticated organisational structure designed for massive scale, speed, and reliability.

Architecture isn’t about guessing a specific company’s design; it’s about mastering universal patterns that solve problems like managing complex codebases and scaling teams. We’ll walk through the essential patterns — from organising a single file to deploying hundreds of independent services — using the development of a major ordering app as our guide.

2. Foundation 1: The Layered Architecture (Organising One Service)🏗️

While building any application, the first challenge is organising your code. Layered Architecture solves this by enforcing a strict separation of concerns into horizontal layers.

Analogy: Think of a Restaurant Kitchen. Each station has a specific job and only communicates with the station directly above or below it.

In our ordering app, the layers would look like this:

Key Takeaway: This structure ensures the core business rules are isolated from database code and the UI, making the application testable and maintainable.

3. Foundation 2: Model-View-Controller (MVC) (Structuring a Feature) 🧩

Model-View-Controller (MVC) is the design pattern that structures a single feature(Checkout screen) within the Presentation and Application layers.

The Crucial Separation: Controller vs. Model

This split defines architectural quality, particularly in validation:

• Controller Responsibility: Input Validation (The “Syntax Check”). The Controller performs checks on the request format using tools like Zod. If a field is missing or the input is malformed, it rejects the request immediately.

• Model (M) Responsibility: Domain Validation (The “Business Rules Check”). The Model handles checks requiring business context:

  • Coupon Eligibility: E.g., Is the cart value over ₹500 to be eligible for N coupons?

  • Payment Rules: E.g., Can a specific type of credit card be used against a particular coupon code?

In practice, the Model is typically split into two modules (classes or services):

1. Business Service: Holds rules and domain validation (calculateTax, applyPromocode).

2. Data Repository (Persistence Layer): Handles all database interactions (saveToDB, loadUser).

4. Level Up: Microservices (The Distributed Ecosystem) 🚀

To handle the demands of millions of users, the ordering app cannot rely on a single-layered application (Monolith). It must transition to Microservices Architecture.

Analogy: We move from one large kitchen to a Food Court where specialised “stalls” (Microservices) operate independently.

A microservice is a small, autonomous application focused on a single business domain, or Bounded Context.

Microservices Breakdown by Domain:

Core Principle: Event-Driven Architecture (EDA)

Services cannot share databases. They communicate asynchronously using Events.

1. Event Publisher: The Catalogue Service (using a afterUpdate hook, similar to those in Keystone or Payload CMS) publishes a MENU_UPDATED Event to a central Message Broker (e.g., Kafka).

2. Event Subscriber: The Search Service subscribes to this event, fetches the updated data via the Catalogue’s public API, and updates its Elasticsearch index.

This loose communication is essential for large-scale resilience.

5. The Two “Cops” Analogy: Gateway vs. Controller🚨

Understanding the roles of the two distinct coordinators is key to the microservices flow:

6. Putting It All Together: A Complete Order Flow

Trace the “Place Order” request through the entire system:

1. User (View) clicks “Place Order.”

2. Request hits API Gateway (Traffic Cop): Authenticates, routes to Order Service.

3. Order Service’s Controller (Elevator Guide) receives request, validates input format (Zod/Yup).

4. Controller calls Order Service’s Business Logic (Model): Runs rules like coupon eligibility, calculates final price.

5. Business Logic calls Persistence Repository (Model): Uses Prisma/Drizzle to saveOrder() to its private DB.

6. Order Service publishes ORDER_PLACED event.

7. Logistics Service and Notification Service subscribe and react accordingly.

7. Conclusion: Building the Next Generation

You’ve moved from understanding how to organise a single function to mastering the architecture that governs the world’s largest digital systems. Architecture is not a destination; it’s a framework for making informed decisions about isolation, scaling, and maintainability. Mastering the strict boundaries between Layers, the clarity of MVC roles, and the independence of Microservices sets you up to build the next generation of scalable applications.

AI used for content editing and image generation

Image from “The Evolution of Trust”

Playing the interactive game “The Evolution of Trust” was a deeply thought-provoking experience, prompting me to examine my own habitual responses in personal and professional interactions.

🤔 The Mirror of Interaction

We often focus on the other player, but what about the “hats” we wear? Our behaviour changes dramatically depending on the situation:

• The Constant Kindred: When someone is consistently kind, do I even notice? Do I acknowledge, appreciate, or try to reciprocate that kindness?

• The Perpetual Antagonist: When someone acts against me, do I try to communicate and understand their motivation, or do I silently stew in resentment?

• The Unpleasant Surprise: When facing a difficult situation, do I take a moment to process and respond thoughtfully, or do I simply react?

I realised that we are not fixed “players,” but rather we adopt roles — sometimes the Copycat, other times the Grudger, and occasionally the Detective. Cultivating a steadfastness in character — putting our minds to action — is key.

📈 Game Theory and the Real World

In an ideal game theory scenario, where players interact repeatedly, strategies like Copycat (Tit-for-Tat) tend to thrive and “win” over time. They begin by cooperating and then simply mirror the opponent’s last move.

However, life is not an ideal scenario.

Limited Chances: We often don’t get multiple chances to evaluate and trust a person. One critical error can lead to a huge loss, and this is what immediately breeds distrust.

The Miscommunication Barrier: Communication today is riddled with potential errors: a toneless email, a laggy video call, or a vague text message. This makes interactions inherently imperfect.

The game confirms that when miscommunication is introduced, the cooperative Copycat strategy quickly evolves into a cycle of mutual cheating.

📉 The Tipping Point of Miscommunication

The results from “The Evolution of Trust” regarding miscommunication are particularly illuminating:

• 0% Error: The fair Copycat wins.

• 1% to 9% Error: The slightly more forgiving Copykitten wins (it cooperates even after one slight misstep).

• 10% to 49% Error: The selfish, unforgiving Always Cheat strategy wins.

• 50% Error: Nobody wins; chaos reigns.

This is why “miscommunication” is such an interesting barrier to trust: a little bit of it leads to forgiveness, but too much and it leads to widespread distrust! I think our modern media technology, as much as it’s helped us increase communication… has increased our miscommunication much more.

~ Game Theory: The Evolution of Trust

💡 What Do We Learn?

The game theory suggests a clear path forward for building stronger relationships:

1. Seek Multiple Interactions: Trust is developed through repetition and consistency. We need enough interactions for a reliable pattern of behaviour to emerge.

2. Embrace Forgiveness: Don’t react to a single miscommunication or misstep. Give the other person the benefit of the doubt, adopting a Copykitten-like strategy.

3. Find Compromise: Look for win-win outcomes — strategies that seek to maximise both parties’ gains in the long run.

GIF credits: Tenor

Imagine you are building a URL spam filter for a service like Gmail. You have a list of 100 million malicious URLs, and you need to check every single link clicked by your 1 billion active users against this list.

The most obvious simple way would be to store the bad URLs in a SQL database and query it every time a user clicks a link.

If you try this in production, your infrastructure will crash in minutes.

In this post, I want to explore why the "obvious" solution fails at scale and how a probabilistic data structure called a Bloom Filter solves the problem by trading a tiny bit of accuracy for massive speed.

The Challenge: The "Scale" Wall

When you are dealing with web-scale traffic, you hit three distinct bottlenecks:

1. Storage: A blacklist of 100 million URLs takes up about 10 GB of space. That’s too big to keep in the fast L1/L2 cache of a standard server, forcing you to use slower storage.

2. Throughput: With 1 billion daily active users, you might face peaks of 30,000 queries per second (QPS). A standard database instance simply cannot handle that many read operations without an expensive cluster.

3. Latency: Users expect instant page loads. A round-trip to a database (network + disk I/O) takes about 2 milliseconds. That sounds fast, but in the world of high-frequency requests, it’s an eternity.

But here is the real kicker: 99% of your traffic is safe.

If you use a traditional database, you are wasting expensive computing resources to check 990 million "safe" links every day. You are effectively burning money to answer "No" over and over again.

The Solution: The Bloom Filter

A Bloom Filter is a space-efficient probabilistic data structure that tells you whether an element might be in a set or is definitely not in the set.

Think of it as a highly efficient gatekeeper. Instead of storing the full URL string (which is heavy), we project it onto a compact array of bits (0s and 1s) using hash functions.

How It Changes the Architecture

We place the Bloom Filter in the memory (RAM) of the application server itself. Before we ever bother the database, we ask the filter: "Have you seen this URL?"

1. If the Filter says "No": The URL is 100% safe. We let the user proceed immediately. No database call. Zero network latency.

2. If the Filter says "Maybe": It might be a malicious URL, or it might be a "False Positive." Only then do we check the database to confirm.

The Impact: By The Numbers

The difference between the "Traditional Approach" and the "Bloom Filter Approach" is not just incremental; it's exponential.

By accepting a standard 1% False Positive rate, we instantly eliminate 99% of the unnecessary traffic that would otherwise hit our database. We shrink a 10 GB problem into a 125 MB solution that fits on the RAM of a cheap laptop.

Industry Adoption

• Google (Safe Browsing)

• Medium (Feed Deduplication)

• Cassandra (Database Speed)

• Akamai (CDN Caching)

• Bitcoin (Wallet Syncing)

Conclusion: The Power of "Good Enough"

In system design, we are often taught that accuracy is paramount. But Bloom Filters teach us that sometimes, knowing what is definitely NOT true is just as valuable as knowing what IS true.

If you can tolerate saying "Maybe" occasionally, but can never afford to be slow, use a Bloom Filter.

For a deeper dive into how bloom filters work with an interactive demo, check out https://samwho.dev/bloom-filters.

Unpacking the “Fragile Hack”: Why the Old Way Fails

The standard method involves hiding the real <input> and using the <label>'s pseudo-elements to create the checkbox graphic. While it looks right, it's a house of cards built on three core failures:

1. Brittle Layouts and Styling

The hack forces the <label> to manage both its text and the checkbox graphic, leading to constant layout battles.

• Manual Positioning: You’re forced to use padding-left on the label to make space, then position: absolute to place the fake checkbox. This is brittle.

• Breaks with Dynamic Content: If the label text changes font size or wraps to a new line, the alignment of the checkbox graphic breaks. Fixing this requires even more complex CSS.

• Style Conflicts: A simple change to the label’s line-height or display property for other reasons can completely misalign your checkbox.

2. Compromised HTML Semantics

This hack violates the fundamental principle of separation of concerns.

• An Element Doing Two Jobs: A <label>'s job is to describe an input. This hack forces it into a presentational role, making it both a label and a graphical button. This makes the code less intuitive and harder to debug.

3. Critical Accessibility Pitfalls

This is the most serious failure.

• Forgotten Focus States: Styling focus states becomes a complex, multi-step process (input:focus + label::before). This is frequently forgotten, resulting in components that provide no visual feedback for keyboard users—a major accessibility failure.

• Failure in High Contrast Mode: A checkmark created with background-color on a pseudo-element often disappears completely in Windows High Contrast Mode, making it impossible for users with vision impairments to see the checked state.

• By using the fragile hack, you lose maintainability, simplicity, and robustness. Your component becomes a chore to update and is guaranteed to fail in common edge cases.

Crafting a simpler, decoupled version

Step 1: Nuke the default style 💥

First, we remove the browser’s default styles with appearance: none. This gives us a blank canvas. We then style the <input> itself to be our box, using em units, so it scales with your text.

input[type="checkbox"] {
/*  reset browser styles  */
  appearance: none;
  -webkit-appearance: none;
  margin: 0;

/*  scale size according to font  */
  width: 1.2em;
  height: 1.2em;
  font-size: inherit;
}

Step 2: Create the base for the container and tick

input[type="checkbox"] {
  /* exisitng styles... */

  /* define the checkbox container */
  border: 0.15em solid #5a5a5a;
  border-radius: 0.3em;
}

input[type="checkbox"]::before {
  /* Setting the base for checkmark. */
  content: "";
  width: 80%;
  height: 80%;
  margin: auto;
}

Defining checkbox container and tickmark base

Two things to notice here:

• The label and the checkbox baselines are not aligned properly.

• We can’t visualise the tick mark base.

Let’s add a background-color: limegreen; on the pseudo selector :before when :checked. We still can’t see the tick base. That is because it needs to be positioned on the UI. Traditionally, it was done using position: absolute;. In modern CSS, it can be done using grid.

input[type="checkbox"] {
  /* exisitng styles... */

  /* center position the tick */
  display: inline-grid;
  place-items: center;
}

input[type="checkbox"]::before {
  /* exisitng styles... */
}

input[type="checkbox"]:checked::before {
  background-color: limegreen;
}

Step 3: Drawing the tick

We use CSS property clip-path and polygon() function to draw are tick on the screen.

/* other existing styles */

input[type="checkbox"]:checked::before {
  background: limegreen;

  /*  drawing the tick mark as x,y points */
  clip-path: polygon(
    0% 65%,
    41% 77%,
    100% 0%,
    46% 100%
  );
}

Use polygon() and clip-path to define the tick mark.

For further enhancements, you can add border-color, background-color, and transform styles to the input when checked.

Step 4: Accessibility and other concerns

There is an issue with this. In Windows high-contrast mode, all the backgrounds are stripped. Only black and white remains. When this happens, our checked state will disappear.

Tick mark disappears in Windows high contrast mode (WHCM)

We can fix this using a neat CSS trick. When Windows forces black and white colours, we add a CSS media query to ensure the background picks the available system colours.

We have 2 options :

• Highlight: This keyword maps to the system’s “selection” or “accent” colour (often blue by default).

• CanvasText: This keyword maps to the default text color in the user’s OS theme. In a light high-contrast theme, it’s typically black. In a dark theme, it’s white.

@media (forced-colors: active) {
  input[type="checkbox"]:checked::before {
    background-color: Highlight;
  }
}

Similarly, handle accessibility for keyboard by styling :focus-visible for the input. And, the :disabled and :read-only states with cursor: not-allowed to give a clear idea to the user. We can also use the aria-checked HTML attribute for screen readers.

Step 5: Automating using CSS variables (optional)

Furthermore, we can use CSS variables to style the checklist based on the section background colours. This helps the checklist seamlessly blend with the flowing content.

For automating this, I use 80% of the current text colour as the background colour

/* keep existing value as fallback for older browsers*/
background: limegreen;  
background-color: var(--checkbox-bg, rgb(from currentColor r g b / 80%));

Note that we haven’t touched the label element. We can now independently style it as a common component for all input types without worrying about disturbing the checkbox styles. This also helps maintain the semantic HTML structure.

Key Takeaways

• ✅ Use appearance: none on <input> to reset browser styles.

• ❌ Don’t hide the input and style the <label>.

• ✅ Use clip-path and polygonfor a clean checkmark shape.

• ✅ Use display: inline-grid for centring.

• ✅ Build for Scalability: Use em units for sizing so your checkbox scales with the surrounding text, and use CSS variables for easy theming.

• ✅ Prioritise Accessibility: Always include a clear state for keyboard users. Use the @media (forced-colors: active) query to provide an alternative style for Windows High Contrast Mode.

• ✅ Avoid accidental shrinking: I prefer adding flex-shrink:0; as a fail-safe in my input to avoid accidental shrinking in a possible flex parent. You might miss these if it only happens on smaller devices.

Image shows accidental shrinking in flex-parent, especially in mobile devices.

Over to You

I wrote this guide with an intention to provide a solid foundation for modern checkbox styling, giving you techniques you can carry forward into more advanced components.

But this is just my take, and I’m always eager to learn from the community. I’d love to hear your thoughts — did I miss anything? Have you run into a specific edge case where this might fail, or do you have a different technique you prefer? Accessibility concerns?

All suggestions and critiques are welcome in the comments below. Let’s learn from each other!

Need the same icon to work on both light and dark backgrounds? We usually change the color in iconsets. But what about site logos or custom icons downloaded from Figma? Do we make the user download multiple files just to handle a complex gradient change?

Instead, we should identify the hard-coded values in the SVG. If you read the SVG code, you’ll notice that the colour often comes from a block of linearGradient code. Specifically, the stop-color attribute. This might vary for other SVGs, so look out for fill and stroke parameters. They may contain direct colours or point to another element using the url function. If a url is used, locate the <defs> element with the corresponding ID (Image shows path pointing to <defs> with ID “g1“

Strategy 1: The Custom Component (CSS Variables)

How do we do this with a single SVG file in React?

1. First, save the SVG as a component rather than importing it as an image.

2. You need to replace the static ID (like "g1") with a unique, dynamic ID. This is crucial because we are referencing a DOM element in the fill by its ID. It will always take the value of the first occurrence in the DOM, so if different instances need different colours, they require a unique ID. Also, don’t miss the hash (#) symbol when writing the url access string.

3. Finally, assign CSS variables to the stopColor attribute. I prefer adding a default fallback value to the variables for safety, like var(--color, "#455673").

You can now use a single SVG component for multiple variations.

Strategy 2: The "External Defs" Trick (For Icon Sets)

What about icon sets like Hugeicons? Often, gradient features are locked behind "Pro" tiers, or the library simply doesn't support them.

We can bypass this by defining a gradient in a separate, invisible SVG and referencing it in the icon's stroke.

Step 1: Create a Gradient Definition Component

This component renders an invisible SVG (height=0, width=0) that serves purely as a container for your gradient definition.

const SVGDefinition = ({ id, className }) => {
  return (
    <svg 
      className="absolute inline h-0 w-0" 
      aria-hidden="true" // Good for accessibility since this is invisible
    >
      <defs>
        <linearGradient
          id={id}
          x1="0" y1="0" x2="0" y2="100%" // gradient
          gradientUnits="userSpaceOnUse"
          className={className} // If using Tailwind classes for colors
        >
          {/* Use stopColor (camelCase) */}
          <stop offset="0%" stopColor="var(--gradient-from)" />
          <stop offset="100%" stopColor="var(--gradient-to)" />
        </linearGradient>
      </defs>
    </svg>
  );
};

Step 2: Apply it to the Icon

Place the definition alongside your icon, then override the icon's stroke style to point to your new gradient ID.

const Component = () => {
  const gradientId = 'unique_gradient_id'; // Descriptive variable name

  return (
    <span className="relative">
       <SVGDefinition id={gradientId} />
       <IconFromIconset 
         style={{
           // React inline styles require quotes and comma separation
           stroke: `url(#${gradientId}) !important`, 
         }}
       />
    </span>
  );
}

Why this works

The url(#id) syntax in SVG doesn't care where the ID live. It just looks for a matching ID anywhere in the DOM. By injecting our own <defs> nearby, we can "paint" the third-party icon with our custom gradient.

Notes:

1. The defined gradient needs to be position absolute with width:0 and height:0. This ensures it doesn’t take up any physical space on your page.

2. If this gradient is a primary brand colour used everywhere, you can simply add this definition to the top of your body tag to reduce overhead. You wouldn't need a wrapper in that case, just use the icon with the adjusted stroke value.

I have tested this approach on size, stroke widths, fill, and filter attributes. Let me know if you find something intersting or have any feedback :D

References:

1. https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/defs#/

2. https://developer.mozilla.org/ru/docs/Web/SVG/Reference/Element/linearGradient#/

3. https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/stop-color#/

Previously published on Medium

By the end of this blog, you will have a clear understanding of Web Storage APIs, how to implement them, and most importantly, when not to use them.

Prerequisites

To get the most out of this guide, you should have a basic understanding of:

• JavaScript (Objects, Strings, and basic syntax)

• APIs (How interfaces interact with the browser)

• Client side rendering (How the browser paints the UI)

What is the Web Storage API?

The Web Storage API provides mechanisms for browsers to store key value pairs. Unlike cookies, this data is never sent to the server with every HTTP request, reducing network traffic.

There are two main mechanisms within this API:

1. LocalStorage

2. SessionStorage

Both share the same storage limit (typically around 5MB per origin) and use the same methods to set and retrieve data.

1. LocalStorage

localStorage persists data even after the browser window is closed. It has no expiration date; the data remains until the user manually clears the cache or your web app clears it programmatically.

Common Use Cases

• Storing User Theme preferences (Dark or Light mode).

• Persisting authentication tokens (caution advised).

• Saving "draft" data for long forms.

Syntax

// Save data (Key, Value)
localStorage.setItem('theme', 'dark');

// Retrieve data
const currentTheme = localStorage.getItem('theme');

// Remove specific data
localStorage.removeItem('theme');

// Clear all data
localStorage.clear();

2. SessionStorage

sessionStorage works almost exactly like LocalStorage, but with one key difference: Persistence. Data stored in sessionStorage is cleared as soon as the tab or window is closed.

Common Use Cases

• One time login redirects.

• Sensitive banking session data (where you want automatic cleanup).

• Filtering or sorting states for a specific tab.

Syntax

// Save data
sessionStorage.setItem('sessionID', '12345');

// Retrieve data
const session = sessionStorage.getItem('sessionID');

Cons of Web Storage API

While localStorage and sessionStorage are incredibly easy to use, they come with a significant architectural flaw: They are Synchronous.

JavaScript runs on a single main thread. This thread is responsible for everything: executing your JavaScript, parsing HTML, and rendering the UI (painting pixels to the screen).

Because Web Storage APIs are synchronous, when your code reads from or writes to storage, the browser halts the entire main thread until that operation is complete.

The Performance Impact

If you are storing a small string, the delay is negligible (microseconds). However, if you are storing large datasets (approaching the 5MB limit) or complex JSON objects that need to be serialized or deserialized, the impact becomes noticeable.

1. UI Freezing: While the browser is writing to localStorage, it cannot respond to clicks, scrolling, or animations. The app will feel "janky" or unresponsive.

2. I/O Blocking: Reading data from the disk (where storage lives) is much slower than reading from memory (RAM).

Warning: Never use Web Storage for high frequency data (like tracking mouse movements) or large datasets (like a list of 10,000 products).

Summary: Advantages and Disadvantages

Ease of Use

• Pros: Extremely simple API (setItem and getItem). No setup required.

• Cons: Limited to Strings only (must JSON.stringify objects).

Persistence

• Pros: Great for saving state across sessions (LocalStorage).

• Cons: Data can accumulate and waste space if not managed.

Performance

• Pros: Fast for very small amounts of data.

• Cons: Synchronous and Blocking. Can freeze the main thread and degrade UI performance.

Security

• Cons: Vulnerable to XSS. Any JavaScript running on your page can read this data. Never store sensitive secrets here.

Better Alternatives and Best Practices

If you need to store complex data or large files without slowing down your app, consider IndexedDB. It is an asynchronous, transactional database system built into the browser. It does not block the main thread and can store significantly more data than Web Storage.

I have listed down a few articles below that dive deeper into these alternatives and best practices. Do check them out to deepen your understanding.

References and Further Reading

• Storage for the Web (web.dev)

• The Different Types of Browser Storage

• Client Side Storage Options Comparison

• JavaScript.info: LocalStorage

• MDN Web Docs: Web Storage API

• GeeksForGeeks: LocalStorage and SessionStorage

• Complete Guide to Local Storage

Knowledge of storing, retrieving, and structuring data is vital for software developers. It allows them to create cost-effective applications that are not only easy to use but also fast and efficient.

However, knowing the definitions is just a small part of the puzzle. The key factor is practical usage. Don't just gather information; try to understand why structures are designed the way they are. Deeply understanding the logic behind these structures helps you retain the knowledge for longer periods and apply it effectively to real-world problems.

1. The Stack

The best real-world example of a stack is the "Tower of Hanoi" puzzle. In this structure, a ring can be removed only if the ones above it are removed first. Similarly, new rings can only be added to the very top of the existing ones. No ring can be added to the middle or removed at random.

Technical Breakdown: LIFO

Stacks function exactly like the rings. In technical terms, this is called LIFO (Last-In-First-Out). The element placed last is the first one to be removed.

• Push: The action of inserting or adding an element to the stack.

• Pop: The action of removing an element from the stack.

• Entry/Exit: The same point (the top) is used for both entry and exit.

Common Applications: The most common application of a stack is during recursion and managing function calls in programming languages.

2. The Queue

Unlike stacks, a queue has two control points: one for entry and one for exit. Take a one-way road as an example. You can only move in one direction. If you are stuck in traffic, you cannot cut in front; you have to wait for the person before you to move.

Technical Breakdown: FIFO

Technically, this is called FIFO (First-In-First-Out) or "First Come, First Served." If you book your movie ticket first, you get the seats first.

• Enqueue: The action of inserting an element into the queue (joining the line).

• Dequeue: The action of removing an element from the queue (leaving the line).

  

Types of Queues

• Linear Queue: This is the standard road traffic. You enter at the back and leave at the front.

• Circular Queue: Imagine the road connects back to the beginning. If the end of the queue is reached, but there is empty space at the start (because cars have left), new elements can wrap around to the beginning.

• Priority Queue: Imagine you are in a hurry to reach a destination. Because reaching that place is a priority, you go faster. Example: an ambulance bypassing traffic. In data structures, if an item is tagged with "high priority," it is processed before others, regardless of when it arrived.

Common Applications: Queues are used when tasks do not need to be done immediately but must be organized. Examples include mailing services, printer buffers, and CPU scheduling.

The Science of Color Theory

While intuition plays a role, color theory provides the roadmap. At its core is the Color Wheel, a visual organization of color hues around a circle. Understanding the relationships between these hues is the first step to intentional design.

• Primary Colors: Red, Blue, and Yellow. These are the roots of every other color and cannot be created by mixing.

• Secondary Colors: Green, Orange, and Purple. These are formed by mixing two primary colors.

• Tertiary Colors: The result of mixing a primary and a secondary color, giving us complex hues like blue-green or red-orange.

Beyond the wheel, you have Temperature. Warm colors (reds, oranges, yellows) tend to evoke energy and action, while cool colors (blues, greens, purples) generally provide a sense of calm and professionalism.

Decoding Color Psychology

Colors do more than look good; they trigger specific psychological responses in your users. This is crucial for branding and conversion.

• Blue: Trust, security, and stability. This is why it is the dominant color in fintech and social media apps.

• Red: Urgency, excitement, and passion. It is perfect for "Buy Now" buttons or error states but can be overwhelming if overused.

• Green: Growth, health, and success. It is the universal sign for "correct" or "completed" actions.

• Black & White: Sophistication and clarity. Luxury brands often use monochrome palettes to let the product speak for itself. Example: Apple Airpods site

Mastering Schemes: Monotone and Duotone

When in doubt, simplifying your palette can lead to the most striking results.

Monotone (Monochromatic) This scheme uses a single base hue but varies the saturation and lightness to create different shades and tints. It is arguably the safest way to design because the colors are guaranteed to match. It creates a clean, cohesive look that is very easy on the eyes.

Duotone As the name implies, this relies on two contrasting colors. It was popularized by Spotify and is excellent for making a bold statement.

The Golden Rule of Balance: 60-30-10

Once you have your colors, how do you apply them without making the UI look chaotic? The interior design rule of 60-30-10 works perfectly for web interfaces:

1. 60% Primary Color: This is your neutral background (whites, soft grays, or dark mode bases). It sets the stage.

2. 30% Secondary Color: This is your brand color. Use it for cards, headers, or distinct sections to create visual interest.

3. 10% Accent Color: This is your "Call to Action" color. Use it strictly for buttons, links, and critical notifications to draw the eye immediately.

Handling Bright Colors

While they are fun, bright colors should be used sparsely. Staring at highly saturated colors for long periods causes eye strain and fatigue. However, they are powerful tools when used correctly.

Because our eyes are naturally drawn to sharp, bright colors, they make excellent highlighters. Yellow, Orange, Red, and Neon are best used as accents. Their muted versions can be used for backgrounds to soften the page.

Designing for Comfort: Low Blue Light

Ever wondered why "Dark Mode" feels so much more comfortable? Colors with high levels of blue light often cause eye strain. This is why a stark white background can be tiring to look at.

Instead, try using tinted or neutral shades for your backgrounds. The key is to minimize green and blue tones in your base colors to create a softer, more readable experience.

Tools to Help You Choose

You do not need to guess. There are powerful tools that can generate accessible and harmonious palettes for you:

• Adobe Color: The industry standard. It allows you to browse trends, extract themes from images, and check contrast ratios to ensure your text is readable.

• Canva: Great for beginners. Their color palette generator can instantly pull the dominant colors from a photo you plan to use on your site.

• Coolors: A super fast generator that lets you lock in colors you like and hit the spacebar to cycle through matching options until you find the perfect set.

Final Thoughts

The key is simply to find the right level of contrast between the text and the background. Just remember to choose pleasing colors that serve a purpose.

References:

1. Color Theory:

   1. https://www.canva.com/colors/color-wheel/ (blog)

   2. https://www.canva.com/design-school/resources/understanding-color-theory#/ (Video)

2. Color Meanings:

   1. https://www.canva.com/colors/color-meanings/

   2. https://www.adobe.com/creativecloud/design/discover/color-meaning.html#/

3. https://www.videomaker.com/how-to/editing/color-correction/adobe-color/#/

4. https://www.digitalsilk.com/digital-trends/neon-color-palettes

5. https://lifestyle.sustainability-directory.com/learn/why-do-highly-saturated-colors-cause-visual-fatigue/#/