AI editors

The primary AI editor I used for development was Kiro from Amazon. Kiro, like Cursor, is an AI-native integrated editor. It too is built on the Visual Studio code platform.

AI-native editors bring a chat-like experience front and center rather than an editor experience with an enhanced auto-complete. The first versions of Github Copilot brought ground-breaking autocomplete to regular IDEs. However, that was so 2022. Newer AI-editors do a lot more complex tasks.

The primary method of AI-editing is called vibe coding where you can iterate over changes. This can be asking about the codebase or making changes.

Kiro also brings a different experience called Spec driven development. Interaction begins with a chat experience, but the output from this stage is a triad of docs as part of a specification. The component docs in a specification are-

- Requirements - user stores and acceptance criteria in a structured form of WHEN -> THEN

- Design - technical architecture and implementation concerns.

- Task list - implementation plan for a step by step approach for solving the broader problem.

With specifications, you are forced to think through what you want to build and how. Further these serve as context for the LLM generator as changes are incrementally made. Technically the specifications are simply text based markdown files. Diagrams generated are also based on textual mermaid tool. In the latest version of cursor, it does generate a plan as well before going through a change which is similar to a spec. However a spec is committed and hence also helps as a future reference point.

Workflow changes

The new AI based tools are definitely able to accelerate productivity for small projects. With very little direct effort I was able to produce a medium sized project.

These tools still require solid technical understanding but do not require deep technical work anymore. My day job as an architect requires me to make a lot of high-level decisions and drive architecture and hence such tools fit how I work.

These tools are becoming more advanced in many ways. There were a few times when the proposed design of a spec from kiro was better than what I had expected. There were newer versions of some AWS services and the tool was able to offer a better solution.

At the same time, these tools have a strong inclination of generating tons of verbose code. Even in my project I have some duplication which as a human author I would try and refactor into a common library. But my tools are making me lazy.

Coding no longer requires deep thinking. Instead you fire off a few commands and hope for the best. In theory, I can review the output from each task and then trigger the next one. However after the initial euphoria waned off; I just started triggering all the tasks in a spec and then went away to other chores. There were a few instances where I had to scrape off a complete feature since the output was not what I expected. Few steps forward and some backward. Understanding how to give well scoped tasks will continue to be what a good engineer does. I’m not yet confident in multiple agents autonomously making changes to a codebase.

Looking into the future

The bar for junior software engineers to enter the industry is going to be higher. With AI tools like these; there is clearly going to be a shift of work from humans to agents.

Code reviews become critical with such tools. However at the same time it will not be easy to humanly review large code dumps. Hence it is likely that code review agents become more prevalent which are able to validate code style and other lesser concerns. For the bigger picture well written and tested specs should be enough.

Programming itself has become easier. And hence we will generate more code and not less. However the true cost is typically around maintenance and migrations. Hence understanding these complex custom solutions to humans and making large scale changes will be a big area. Tools like Codewiki might be interesting to follow.

Welcome to US Visa Bulletin Hub, your new essential tool for navigating the complex world of U.S. immigration and Green Card priority dates.

I’m excited to announce the launch of my latest project designed with one simple mission: to help you stop wasting time refreshing the State Department website and start planning your future with confidence.

The Problem: The Waiting Game

If you are in the queue for an employment-based Green Card (EB-1, EB-2, or EB-3), you know the struggle. Every month, you anxiously await the release of the U.S. Department of State’s Visa Bulletin. You scroll through complex tables, cross-referencing your “Final Action Dates” with “Dates for Filing,” trying to see if your priority date has finally become current.

It’s stressful, confusing, and easy to miss critical updates that could affect your status.

The Solution: Instant, Personalized Alerts

US Visa Bulletin Hub solves this problem by bringing the updates directly to your email inbox. Instead of manually checking and comparing bulletins every month, we do the heavy lifting.

Key Features:

• Personalized Tracking: simply select your Visa Category (EB-1, EB-2, EB-3) and your Country of Birth.

• Instant Notifications: Receive an email the moment the new Visa Bulletin is released and updated for your specific category.

• Clear Insights: Our notifications highlight exactly what changed, so you don’t have to decipher the charts yourself.

How It Works

1. Visit USVisaBulletinHub.com.

2. Select Your Preferences: Choose your specific employment preference category and country of chargeability.

3. Sign In: Use your Google account to securely sign up for alerts.

4. Relax: We monitor the official bulletins 24/7. When there is movement in your category, you’ll be the first to know.

5. Share: Share the link if you find it useful.

Adoption of the standard has been rapid.

• Anthropic released MCP for Claude in November 2024

• OpenAI added agent SDK support recently

• Microsoft also added support in various forms

  • For AI apps in Copilot studio

  • For their open-source projects like playwright. Playright can perform browser automation and will be able to act like operator

• SDKs from popular languages like typescript, python, Java by spring, kotlin by JetBrains, C# by Microsoft.

• The ecosystem has exploded for official and community-based MCP systems. See catalogs at github, MCP Servers  and glama.

In this blog, I’ll provide technical details about the protocol.

What is context?

The primary purpose of MCP is to provide context (data and actions) to models (large language models like chatgpt, claude). Models are tuned based on public data and later optimized for certain use-cases via fine-tuning. However models do not update based on newer knowledge or have access to proprietary or local data. Hence additional data aka context can be provided to a MCP to make it relevant for a wide range of tasks via MCP. By having an open-standard it is possible to mix and match implementations for building complex solutions.

Arstechnica explains this well in their article.

Base protocol and architecture

MCP is a stateful protocol for exchanging messages between clients and servers. This makes the systems more complex compared to a stateless protocol like REST or GraphQL.

The underlying messaging format is based on JSON-RPC v2.0 (Remote procedure calls using JSON format).

Request from client to server

{ "jsonrpc": "2.0",

  "id": 1,

  "method": "resources/read",

  "params": { "uri": "https://en.wikipedia.org/wiki/JSON-RPC" }

}

Response from server to client

{ "jsonrpc": "2.0",

  "id": 1,

  "result": {

    "contents": [ {

        "uri": "...",

        "mimeType": "...",

        "text": "..."

    } ]

  }

}

There are three types of messages-

• Requests: Client or server can initiate a request which is identified by an ID. It includes method and parameters.

• Responses: Successful or error response for a request (with ID)

• Notifications: One way messages without any request ID

Request/Responses are asynchronous and both client and server need to keep track of the session and requestId to match.

A typical interaction will be like

• Host (app) initializing a client which initializes a server session. For a complex app that integrates with multiple services, there will be many client-server sessions at one time.

• Discovering  features (capability negotiation) like resources, tools etc

• Performing certain AI related tasks for the lifetime of the host

• Termination commands

Server features

Servers expose the following optional primitives-

Resources

Read only resource endpoints typically exposed by servers via REST/GraphQL. These are meant to be invoked by the AI Application. Messages include

• Listing resources for discoverability with support by pagination

• Reading resources

• Reading parameterized resources based on URI templates.

• Notifications and subscriptions for changes.

Tools

Write, mutation or complex action endpoints. Functions or actions exposed to the LLM. These are typically API POST requests. These are Model controlled. Message examples include-

• List tools with input required and description

• Call tool with arguments. Result of a tool call can be content or resources.

• Get notifications for changes in tools

Prompts

For AI applications, Interactive prompt templates are filled based on user choice. These are user controlled. Messages are

• Discover available prompt templates with arguments and descriptions

• Getting a prompt with arguments for the template which causes a response content.

• Get notifications on prompt template changes.

Other server features include ping, completion and logging. I’ll skip advanced client features.

Composability and interop

Another major design feature is composability.

• Breadth - Each server can support limited functionality. Maybe only resources or tools or a combination of both. The client is supposed to discover the capability of a server dynamically. A host app can compose a solution by creating many client sessions with various servers.

• Depth - A server can provide higher order API by aggregating capabilities of other servers. The Aggregate server can have auth and internally have client sessions to other downstream servers.

Thus it is possible for different tool, resource and LLM providers to provide smaller solutions which can then be aggregated for solving very complex problems.

Consider the use-case of asking your AI assistant to search for a recipe, order the items and buy them. This was the operator demo. It should be possible to do this by

• tool like playwright as a browser driver

• tool like brave search for internet search

• LLMs like claude

• any website for shopping and checkout (natively or via internet browsers)

Authorization

For remote server connectivity, authorization support was added in v2025-03-26 based on OAuth.

For direct client to server connections, OAuth 2.1 for public clients using PKCE (important for public clients (like mobile apps and Single Page Applications) where client secrets cannot be securely stored) is used. Third party auth flow is also supported for server based applications.

What’s next

MCP has prioritized getting a local version of the tooling out first based on standard I/O communication. This allows for completely local tools to be built. Examples of local protocol includes local files, and browsers. This has led to a bottom-up growth of adoption which is now forcing large players to also provide integrations and support. This allows for exciting tooling to be built for scenarios like home automation. Multi-language SDKs lower the bar on adoption.

However, the specification is still in fairly early days. There are going to be extensions for complex scenarios like aggregating servers, transforming data, streaming results, multi-modal results, sandboxing for security, and more.

The video above by Andrej Karpathy is a fantastic overview of how Large Language Models (LLMs) work for a non-technical audience. It is as long as one bollywood movie but introduces many concepts, explains the possibilities and limitations of LLM based models.

Here is a quick summary of the video followed by some opinions.

Products from companies openai, meta, deepseek and others follow the following steps to make LLMs.

• Pretraining - Large volumes of data are downloaded and indexed. Data is essentially all of the internet including books and other forms of media.

• Tokenization - Convert data into internal encoded formats.

• Neural network training - For an input token sequence, predict the next possible sequences. By "training" the model in reducing loss the neural network is able to learn characteristics of the data. The scale of the computation required for this is extremely large and something that I'll try to expand on in a future blog.

Post training it is possible to query the model to be able to predict the next token given an input sequence. These are base models which can be used for many applications.

To make end user facing applications, companies perform post training "supervised fine tuning" (SFT). This involves providing sample queries and answers as a prompt to the base model so that it can provide answers in a certain format. Specific examples and responses are used to make the model respond in a certain way for various classes of queries. For example, getting information about nuclear weapons should not be possible. With these examples the model is updated and it has preferred paths to respond to queries.

The newer generation of models are based on a post-training mechanism called reinforcement learning. These are called reasoning models.

Rather than providing the explicit steps for being able to get an answer for a question, just a final answer is provided. These questions can be asked many times and different answers can be obtained. The responses from the model are used to compare to the valid answer and the model is then incentivized to accept certain answers.

With reinforcement learning, the model is able to find out unique pathways to finding correct answers which were not hinted at by humans. This will enable unique solutions in the future.

Such techniques were used by systems like alphago to outperform human players in a board game. Alphago was trained on a closed domain problem with specific rules and hence the model could simulate against itself to learn new moves. Similar benefits can be expected in other fields.

Magical Emergent properties

As AI systems have been growing larger to handle more complexity, emergent properties have occurred. In the previous generation SFT based models, at high scale the understanding and generation of text was human-like.

With a large number of tokens used for reasoning models, there is a newer emergent property - Chain of thought. Instead of providing quick answers the model is able to break down a problem and optionally verify answers. For a query like "explain logarithms" the truncated chain of thought generated by the LLM was 

My thinking process to generate the explanation of logarithms followed these steps:

1. Identify the Core Concept
2. Start with the Familiar
3. Introduce Logarithms as the Inverse Question
4. Formalize the Notation
5. Highlight the Equivalence
6. Provide Concrete Examples
7. Address Common Logarithms
8. Explain "Why Logarithms are Useful"
9. Introduce Key Logarithm Properties
10. Summarize and Reiterate the Core Idea
11. Structure and Clarity

Self-Correction during the Process
- Initial thought
- Correction

By following these steps and incorporating these self-corrections, I aimed to create a clear, comprehensive, and easy-to-understand explanation of logarithms.

This intermediate input was then used by the LLM to provide a long detailed and structured answer. Such models will become more prevalent with increasing competition and technological advances.

Emergent properties are not explicitly programmed or seen in smaller components. Another cultural reference that I am reminded of is from the movie Tron Legacy. In the movie, there is a species of programs called ISOs which appear out of nowhere. Although these programs have immense potential to solve many problems faced by humanity they are destroyed by other programs.

Future Impact

Data and APIs

AI systems need enormous amounts of data. The leading companies in the AI race have scraped all public data from the internet without respect of copyright law. Next they will try and scrape data from private sources via clients like browsers. Further they will try to limit access to the data that they own.

There are new tools like Operator which can control browsers based on inputs to perform various tasks. The demo for operator shows a task to search to get a recipe and then place the ingredients required into a shopping cart. With such tools it is possible for the system to compose functionality across many sites in a logged in context. In the short term it will mean that APIs become irrelevant. I’ve been a proponent of well designed APIs for a long time. However building UIs without APIs is simpler. Now since integrations can be done without APIs and can serve users as well it is likely that this causes lower investments in public APIs. A limited public API also serves to limit data access.

Verifiable domains

Maths and programming are verifiable domains. For a given task it is possible to test the solution by writing tests. These tests can be generated by the LLM and thus multiple solutions can be automatically verified. For such verifiable domains, LLMs can generate solutions with minimal human input. This will lead to extremely fast progress in these domains to superhuman levels. Entry level programming tasks will be automated soon.

LLM based tools cannot be used for tasks that are critical in nature since hallucinations are still a possibility. For non-verifiable domains, human input will still be needed to confirm actions. Self driving cars were a problem domain which had a similar complexity curve. Level 5 autonomy has not been solved and seems to be a much harder problem than earlier anticipated.

Competition 

There is an intense competition across various companies to push the technological frontier forward. Innovations are published in research papers and models are being released as open weights. This will allow smaller companies and individuals to also benefit from the advances albeit constrained by how much compute they can afford. Society is going to have to go through enormous change as many job functions will be re-defined. It will be better for a wide array of actors to be able to use these technologies rather than be limited to a few.

For future innovation, most companies believe in the AI scaling law which refers to the observed relationship between the performance of AI models and the resources used to train them. It essentially states that as you increase the size of the model (number of parameters), the amount of training data, and the computational power used, the performance of the AI model tends to improve.

Reasoning models require enormous compute (tokens used) compared to SFT based models. It is expected that with further increase in compute even better gains will be made with emergent properties leading to general intelligence or robotics.

To address the growing compute needs, companies are investing in setting up new data centers and also power generation plants. I doubt the world will reach targets of emissions especially since the current US administration has already withdrawn from the Paris Agreement.

The race for dominance has shifted from companies to the biggest two nations - US and China. Hopefully competition will remain limited to the technological space and not spill over to an actual war. There are enormous pitfalls and promises at the same time and this is a transformational period for humanity.

I got this email in my inbox at around 9:46 AM today which is the Monday of layoffs!

I don’t want to blame the recruiter who is trying to do her job. Or this is probably from an automated script that was not turned off.

But, I often wonder how executives manage to dehumanize and commoditize others who they are supposed to lead.

We recently completed a home improvement project to install ethernet cables in our old home and I'll share my experiences in this post. We already had a gigabit internet connection and a wifi 6 router with dual bands. Theoretical speeds are supposed to be ~2gbps throughout our relatively mid size home. However practically I used to get around just 120 mbps peak from my desk. There are also some wifi black spots where the wifi speed dropped to around 20mbps. Generally we have a usable network for the most part. However the number of devices and media consumption in the house has been increasing - summer vacation with kids at home! That caused further load degradation of the network.

After setting up the new network, connection speeds to the internet are maxing out at around 900Mbps. Buffering during streaming and video calls has massively reduced which is a perceptible change.

I did research options for improving my network. A mesh wifi upgrade could be an option for some. However the newer mesh systems also cost over $1k and now include subscription services. Getting a wired connection setup was more painful than upgrading wifi but feels more future proof.

This article had many good pointers on setting up a wired home network. The first step was planning where the devices would be placed. I have the internet modem and router in one bedroom, and planned to add a switch in the shoe closet in the center of the home. Each room now has a couple of ethernet ports.

For ethernet cabling, there are many options, but I ended up with a basic CAT 6 cable. CAT 6 has a theoretical speed of up to 10 Gbps for a distance till to 55m or 180 ft which was more than sufficient for my home. The devices that I have support up to 1Gbps only anyways so it feels like this setup should last for some time. In US homes, adding ethernet wiring is simpler because of the wooden and drywall walls. If you cannot drill, then adding an external channel can also work to connect wires.

The project was partly DIY since the electrician did set up any jacks and I got to do some of that. In the walls, keystone jacks needed to be set up. Splicing the ethernet cable, attaching the wires to the jack with a punch down tool and testing with a network tester are needed. There are a few basic tools needed for this. Making ethernet cables was interesting with pass through rj45 jacks as well. Got to use some more tools for that task.

All the wires from the rooms end up in a central location where you need to add a switch. I decided to build a mid-range setup with a server rack. For a neater use of cables, there is a jack connection panel called a patch panel. I've shifted some smart home devices there too. In the future adding a storage device should also be possible.

Smart home automation should be the next major project once I can secure spousal funding.

Temperatures in California were in the 40+ C reaching almost 47 during the day. An excessive heat warning was declared for 30+ million people or over 10% of the US population. At such a scale, there is nowhere to go and at the same time all you can do is hunker down and try to remain cool.

At the same time, given the dry summer and heat it is easy for fires to break out. The live map snapshot from fire.ca.gov below shows multiple active fires.

At such temperatures systems fail in interesting ways. Our air conditioner for the house was providing cooling, but still in high 30’s C. Only at night did temperatures reduce enough to be pleasant. Hence we were constantly trying to avoid the heat throughout a major portion of the day. In older (or historic) homes with insufficient insulation, this can be a major issue. Solar panels actually operate efficiently at about 25 C. Hence at higher temperatures there is actually a reduction in electricity generated. The risk of a grid failure with many people depending on air conditioners to effectively survive will just increase.

Extreme weather events like these are getting more common now. Climate systems are slow changing. Hence we should expect the frequency and impact of such events to only increase. The cascading loss of not only human productivity but also essentials like water, crops, animal and natural life is going to be devastating. Rich countries like the US which have vast resources will be able to weather the change. Poorer countries like India will need to take aggressive steps today to tackle basics like water security.

Coal consumption especially for energy is only increasing though. The Indian growth engine will be stalled unless solutions are not found.

Unfortunately it seems that humanity is making earth inhabitable faster than we can make mars habitable. Denying climate change is harder now, but taking collective action seems as impossible as before.

Typespec is a new language from Microsoft to define APIs. I've been prototyping with typespec for a few projects and am already sold on the benefits. I’ll introduce the language and tool ecosystem in this article.

In a nutshell, typespec allows you to define a schema with models (entities) and operations (actions) at a high level. Typespec can emit API schemas for targets like OpenAPI 3, Protobuf and others. I've been exclusively using OpenAPI for many years and even for a single protocol, typespec brings many benefits.

model Store {
  name: string;
  address: Address;
}

model Address {
  street: string;
  city: string;
}

@route("/stores")
interface Stores {
  list(@query filter: string): Store[];
  read(@path id: Store): Store;
}

Advantages

Concise language

Typespec is inspired by typescript and is fairly concise. The generated OpenAPI for my projects was around twice in length compared to what was declared in typespec. In OpenAPI, repeating the same errors becomes cumbersome while this was easier in typespec.

Typespec supports namespaces, cross file imports, model composition via inheritance and templating (copying). This rich language helps make APIs concise relative to YAML for OpenAPI.

Tooling

The typespec compiler can be installed as a node package. There are libraries for http, rest and OpenAPI which provide enhanced functionality. The compiler provides errors and warnings making it easy to get quick feedback and iterate quickly.

VS Code has good tooling support for the language as of now along with cli based tools. If your target output is OpenAPI specs, you can continue using any existing tooling in your toolchain as well, like code generators from OpenAPI.

A formatter is provided as part of standard tooling making consistency possible.

Tooling is still not very mature though. Plugins for IDEs like intellij are still not available. However since typespec uses LSP tooling should follow soon.

APIs at scale

Typespec will really provide value in companies with different distributed teams working on APIs. A central team can implement common models and codified standards. Other teams can then extend the models with custom features.

Code reviews and validation of types becomes much simpler with types compared to yaml files.

API versioning

Evolution of APIs is possible with first class versioning support. It is possible to have a single file with multiple versioned models, operations and more. Adding, removing renames and other changes are supported via the library extensions. A versioned typespec specification can generate many independently versioned OpenAPI versions.

Extensibility with libraries

The typespec language is small and there is tooling for creation of libraries which can include

• Typespec types for sharing definitions

• Decorators similar to annotations that can add custom behavior

• Emitters for different targets

• Diagnostics, Linters for rule checks regarding API definitions like naming conventions and more.

Typespec libraries can be written in typescript or javascript. Based on hooks configured the library has access to the AST and APIs to be able to customize behavior. The current extensions for HTTP, REST, and OpenAPI3 are built as libraries and hence the extensibility tooling should be fairly mature.

Getting started

The getting started page and docs on the main page have good examples. For a tech talk view 

For a sample advanced project with common models and versioning see the project I’ve been testing with - typespec-monorepo. I'll add additional patterns as I continue to explore typespec.

API First enabler

I'm a strong proponent of API first (compared to code first) approaches to development. Figuring out what to build before actually starting implementation helps build more intuitive APIs. Using tools like typespec can uplift how teams work with APIs making the process approachable and hence adoption of standards less painful.

Smithy is an alternative to typespec from Amazon. It has fairly similar goals and features. It was released publicly over a year ago. However the website does not have the finesse of the typespec project and I eventually ended up spending more time with typespec instead. Smithy also has a great ecosystem. Typespec is built using typescript, which smithy is java based and that might be a consideration for teams that need custom tooling. Either tool will help with an API first approach at scale.

Decision making is an integral aspect of how companies and teams function. In software technology based companies almost every project involves a multitude of fairly complex decisions that need to be made. Often these are at various impact levels spanning product to technical domains and even planning. Within technical areas too there are broad architectural decisions on how a system can fit into existing architectures, or code related decisions like what code formatting styles are to be followed.

For effective decision making, a fairly well defined process is described in this university course page It covers problem identification, analyzing options, making a choice and final review.

Disagree

In real life, most interesting decisions do not have clean options. Since the beginning of this year itself I've been part of 3 major decisions where the options and data have not been that clear. I've been a participant as a primary stakeholder in one, passive observer in another and a secondary stakeholder in another. I follow the principle of Disagree and Commit when it comes to decision making and strongly recommend it.

When having conflicting options, typically there are some unknown scenarios involved, or personal biases that cause conflict of weighting of pros/cons between options. Stakeholders should add more data or evidence to help consider the options. However disagreement on interpreting the evidence if it is available is still possible. How different groups interpret data is based on priorities and past experience in healthy teams. Personal advancement or team politics can also be strong motivators though not explicitly mentioned in decisions.

Most technical people reason based on analytical arguments and hence look for rational arguments in decisions. However many decisions are based on irrational beliefs or tacit knowledge by a leader.

Commit

If decisions are not made because of conflicting options, then you end up with analysis paralysis. This typically happens when there are multiple committees that need to arrive at a consensus. I strongly favor giving the team that owns the major execution the primary responsibility for the decision. Failure should have implications too. For projects, there should be a feedback loop with checkpoints to validate assumptions behind the decision. Unfortunately for high impact decisions made at high levels I do not typically see the evidence behind the calls or the accountability either.

I have a strong bias for action, and hence favor making progress rather than stalling. In the worst case, choosing the wrong option might lead to losses, but in-action is also a costly option.

The management principle of Disagree and Commit allows individuals to disagree and analyze tradeoffs for various options while a decision is being made; but once a decision has been signed off then everybody must commit to implementing the decision. Introduction of this principle is attributed to Andy Grove the legendary CEO of Intel who has authored many books and articles on management. OKRs were also popularized by him. These techniques show how teams who work towards the same direction can have a big impact compared to split organizations working in different directions.

For frameworks on making decisions, I'll probably expand on DACI and RFC in the future.

In modern life (and definitely in the technology industry) we tend to over index on personal productivity. While I do follow some techniques to achieve goals and targets, I’m not too hard on myself when the environment changes. We do have limited control in the broad scheme of things. Be human. Reset or adapt every now and then. Be nice to yourself and start simple when you need to. There are seasons when you thrive and some when you’ve got to sustain. Here is a picture from our backyard patch this late spring in California with many sprouts taking root.

Most software services deal with data, storing and retrieving it as needed. However, ensuring this data remains consistent can be challenging. There are many options on how data can be accessed after being written based on various architecture tradeoffs. This complexity is further exacerbated in distributed systems spread across multiple data centers. This article discusses the complexities of data consistency in such systems and offers solutions to navigate them effectively. This topic is broad and if there are areas that I’ve missed, getting feedback will help immensely.

Let’s consider a service as a logical concept which is composed of a deployment of multiple stateless compute nodes and private stateful datastores. We explore single region and multiple region deployment scenarios.

Consistency Models

There are three main consistency models for service data-

• Weak consistency: These services are optimized for high throughput, low latency operations with some permitted data loss or reordering. Services that store click streams, log data, metrics or high volume events in parallel are some potential examples. When reading the data, there can be stale reads if some processing is partially delayed.In software design, there's a trade-off between consistency, availability, and partition tolerance (known as the CAP theorem). Let’s consider the CAP theorem as a spectrum of choice from Availability to Consistency since partition tolerance is not configurable. These services are heavily biased towards high availability and sacrifice consistency.
  

• Eventual consistency: Data in these services can diverge for some time (usually a few seconds) under normal operating conditions. Assume that an entity version v₁ is stored at time t₀. It might be possible that at a later time t₁, on querying the service the request falls on a different internal node and you get a previous version of the entity. It is expected that within a short time interval all internal nodes within the service will catch up on the latest value of the entity. Hence the name - eventually consistent.Clients should be fine with a slightly inaccurate view of the data. Some patterns like caching on the writing session or client make at least the writer get a consistent view of the data just written while other clients reading will catch up (see session consistency). Data in this model is typically not lost, and repair mechanisms need to be set up to merge data for a consistent view. Caches might be used in the read paths which lead to inconsistent data for some time.On the CAP spectrum, this model favors availability slightly.
  

• Strong or strict consistency: Data in these services appears consistent. A read after a write should show the last value written. Data for the system as a whole is typically split across shards or partitions and hence consistency can be scoped based on keys or customers or some dimension.This data would be part of some critical infrastructure or business requirement.On the CAP spectrum, this model favors consistency with an acceptable loss of availability.

These 3 categories can be further split into sub-categories based on specific data consistency needs. Most of the services I’ve built have used the eventual consistency model.

When you build modern Saas applications based on independent microservices owning their own view of the data; you are forced with eventual consistency for feature requirements that span multiple services anyways.

In large systems you might also need to support different data types with a mix of requirements. For example, control plane information like sharding information might need a consistent view while data plane information for entity information can be eventually consistent. Hence you can see different models being used in complex systems with differential consistency and availability guarantees.

Ultimately having a good understanding of your requirements is essential in making the right tradeoffs.

Now let’s dive into some advanced patterns for eventually consistent and stricter consistent services.

Designing Eventually consistent services

Region local consistency guarantees

Let’s consider a service that is using AWS DynamoDB as a datastore. Like many modern NoSql datastores, DynamoDb provides tunable consistency. Write operations are durable and will eventually sync across all internal data nodes. During reads, you can read stale or consistent values based on the read consistency parameter. However, this consistent view is limited to a single region.

DynamoDB tables can be configured to work across multiple regions with automatic data replication. There is no way to get a consistent view or configure a transaction across multiple regions. Hence a service deployed across multiple regions with replication configured will need to be eventually consistent. The gain is higher availability. Similar patterns apply to SQL database deployments.

Repair mechanisms

Since it is possible to write two versions of the same entity in different regions, during replication DynamoDb merges changes via conflict resolution. Conflict resolution in DynamoDB is at item scope (single entity defined by key). A last writer wins (LWW) reconciliation strategy between concurrent updates is used, in which DynamoDB makes a best effort to determine the last writer. Designing APIs to make sure that you do not end up with partial inconsistent data within an item because of how data can be merged is important.

CosmosDb from Azure, provides LWW and also custom policies for data reconciliation. I do not have practical experience with this tool though.

Services that depend on data from other services might be out of sync from the latest changes. Typically the source service emits an event stream with changes which can be used to fix the data in dependent services. Other alternatives are-

• Data access based repair. When information is accessed, you can repair data based on some external system but otherwise leave stale data on disk.

  • Sync data on read of the entity with latest state

  • Sync data on write of the entity with latest state

• Run background jobs to automatically repair data in the background independent of access to data. These scans are costly to run in large systems.

Designing Strong/strict consistent services

Single writer

Many services do not actually have active multi-region high-availability requirements. Hence operating in a single region with a local datastore is feasible and also cost effective. In such scenarios you can use SQL stores or even NoSql stores like DynamoDb and achieve consistent writes and hence service level consistency.

An alternative deployment is an active-passive deployment where the passive region acts as a standby. The active region is always replicating data to the standby. On a disaster event, you can change the passive deployment to be the active one. In an active-passive configuration only one region is the source-of-truth at a time. Region failure is derisked with this tradeoff.

Take a detour to read about dataomic which is a database that uses the similar single writer model (transactors) to provide immutable views of data. 

Multi-region writers

At a large scale and a global footprint of clients, supporting multi-region writers typically becomes a requirement. The two patterns that allow for multiple distributed writes is Application layer provided or Database provided.

Application layer provided design takes database sharding ideas to the application layer. A service deployed globally will split stored data into different owned service shards. Let’s assume that a single customer can be mapped to a single designated write region. The service needs to maintain a routing table with strict consistency per customer data subset. Consensus systems like etcd can be used to maintain the routing information across all service shards. Large scale customer data can then be stored in service shards where they are consistent. Multiple independent service shards can independently write across the globe. During disaster events you end up with partial loss of availability. This model also helps with enterprise requirements like data locality.

Database provided consistency is possible with some solutions like google cloud spanner. Spanner effectively promises a consistent-available global store with “external consistency”. I’ve not used this product either but availability of such a platform component should highly simplify complex services.

References

• CAP theorem and the extension PACELC theorem

• Database Consistency Models with formal definitions

• DynamoDb consistency conflict resolution 

• Consistency level choices in Azure Cosmos Db

• Google Spanner consistency and Transactions

To solve the automated display control I used the BH1750 ambient light sensor. This sensor is connected via a few wires and just taped (serious engineering) on top of the pi case. Using the python libraries blinka and circuitpython I was able to add software support for reading the current light value as from the sensor.

With a basic mechanism to read the light lux value, the next step is to write a script that turns the monitor on and off based on xrandr commands. This was described online. A simple python script that looped to read the current status of the light value and turned on or off the display and photo service did the trick. The last step was just wrapping the script as a systemd service. With basic linux administration we have a very workable solution… which works great.

This is the current set up for the photo frame. I followed instructions from https://www.thedigitalpictureframe.com/ to set up the device. The site has a ton of information and is not the easiest to navigate but by the end of the project I found good leads on what I needed to do.

Hardware is a Raspberry Pi 3 with a 15.6" Portable Monitor for the display. They are connected via an HDMI port. I had a spare Pi and hence my cost was the monitor which was around $80 and labor (arguably free).

Software setup and configuration is not trivial for noobs. For most people, I'd recommend a photo frame appliance like Aura. Their 15" models cost around $300 though. This option might be cheaper, but if you end up adding costs to build a good case then it's likely comparable. As a software engineer though, having bare wires in the drawing room feels like a good aesthetic. Let's see how long before anyone else in the house objects.

The base operating system is the Debian-derived Raspberry PI OS. For sharing pictures to the device, samba is set up for file sharing over the local network. The primary photo software is pictureframe. Picture frame loads the photos from the configured folder and displays them based on configuration. After booting up, the Pi automatically starts the pictureframe service which shows the photos in a loop and feels like any other regular digital photo frame.

Advantages of the software are-

• Control over images being displayed. You can select images and share those with the device to be shown.

• Support for multiple galleries. We have a bug folder with the kid's favorites and another one for the family pics. These are just folders in the folder and you can switch based on the mood.

• There are many effects for displaying photos like blending, showing full screen, or a border mat, or motion called ken burns effect

• Photo metadata like location, date, etc can be added.

• Additional metadata like a clock can be added.

• There are advanced features like remote control and automation that I still need to experiment with. Since you are also running a Pi with Linux, you also have access to the Pi extensions like light sensors, or rclone for cloud syncing of photos.

Essentially you get a lot more control than a closed appliance, if you have basic Linux administration capabilities (and patience).

I still have many follow-up tasks on the project to be done.

• Power controls to automatically turn off the monitor are not working.

• Switching of photo galleries is manual via ssh commands. This needs to be made accessible for the family. Maybe some phone app or automation extension.

• Maybe make a wooden frame to hide the wires and give it a respectable look.

• There are currently two independent power supplies to the pi and display. Have to see if those can be integrated somehow.

The current state of the project was a good enough improvement for the family. This is also one of the few times my wife finds my profession useful, so that's another way to showcase some skills. Next, I've got to be able to get sponsorship for additional single function smart frames.

Gratification is the pleasurable emotional reaction of happiness in response to a fulfillment of a desire or goal.

As a software architect, there are some projects that I've been working on for many months. This week a work stream that I helped start almost a year ago finally got completed and reached closure. It was a fulfilling moment and reminded me about the longer cycles of gratification with increased seniority.

Early life as a software engineer was simpler. Most projects had clear requirements and the hard parts were getting the project completed based on technical constraints. Programming languages, software libraries etc were my primary tools. Completing tasks showed clear progress towards completion of projects. Though there were last minute changes in project scope at times, for the most part life was simpler. It was easier to feel a sense of gratification.

Now, as an architect projects are much larger in scope and complex. Laying out the vision for particular areas is hard, requiring knowledge of the current domain and also having a sense of the future. Since projects are longer running, the feedback loops for any gratification are longer and sometimes missed. Contributions on projects are also different at senior levels. At times you are just helping in an advisory role, sometimes helping to initiate a project and raise funding. For a few you work actively and clear out technical hurdles. Often you need to work with stakeholders across functions to solve complex non-technical organizational hurdles. As an individual you need to look at being aware of how your work is impacting the people and projects. Just working without feeling connected or getting the sense of gratification will ultimately lead to a lack of motivation. Hence as a new architect you should be prepared to see a shift on how you will get feedback and hence any gratification. Based on your active or passive participation in a project, set valid expectations.

At senior levels, you are likely also trying to handle many projects or maybe some larger projects with increased risk. I try to balance a portfolio of work with some small low risk and one large high risk project. Projects fail for many reasons. Sometimes the timing is not right. Even if the idea is sound, the supporting environment for the project is not ready. For one multi-year project that we're working on, the environment has changed enabling the same idea but in a completely new packaging. You have to build an intuition and evaluate ideas based on a holistic set of parameters but at the same time be ready to adapt. De-risk projects as much as possible and hope for success. However in the technology industry we have rapid change.  You need to lean into the future and look for common problems. Align with business and chart out where technology is going. Disruption is always happening. Take some bets. You also have to let go of some promising opportunities. Also know that bigger changes take time to take effect.

Recently I started using a feature phone - Nokia 2780 flip instead of a regular smartphone. I'm not that great at self-control and would inadvertently end up spending too much time on my phone. I'm trying an experiment by adding more friction and getting some time and focus back.

Device comparison

iPhone 15 vs Nokia 2780 Flip

Cost

$800

$100

Colors

Washed out pastels

Vibrant plastic colors. The nokia phone is marketed as blue but is definitely green!

Materials

Aluminum and glass

Likely recycled plastics

Primary display

Fancy bright display viewable from 170 degrees

Privacy dim display viewable from 4 degrees

Secondary display

Dynamic island

Closed flip display for notifications and time

Camera

48 mp

5 mp

Cable

USB-C

USB-C

Battery life

Almost a day

2 weeks

Apps

Yes, immensely addictive

Yes, immensely repulsive

Critical features

Phone, messaging, GPS, internet

Phone, messaging, GPS, internet

Arguably both are very comparable.

Trade Offs

The nokia phone is barely usable. It is slow and there are a few apps with minimal versions like google maps, and a browser. However youtube, whatsapp, facebook etc and other social apps seem to be missing. Unlikely that you will get addicted to this phone.

Unfortunately smartphones have become a necessity in modern life. I still have an iPhone setup with apps which I need to keep around and we have other devices in the family like other smartphones, ipads, etc. When traveling I'll need to use maps. For local trips, if I am traveling with my wife we can use her phone with data. Otherwise I can use my phone with offline maps. There are some apps that are necessities like the iRobot app, library apps like libby, many home control apps, and authenticator apps. I have many work apps as well which are optional but make work accessible like slack, confluence and more.

The nokia phone has two major shortcomings, no support for a personal hotspot and no whatsapp. With hotspot, I could have used my smartphone on a few occasions that I needed more functionality. Whatsapp is the messaging platform that I'm connected with most people. Whatsapp is supported on an older version of the operating system but not this current one, which is over a year old. For those interested, the operating system is KaiOS which is a firefox based OS and now owned primarily by a Chinese company. India's Reliance JIO is also a primary user though they seem to be shifting to another Android based OS. Apple is moving to eSIM which will make switching phones challenging in the future. They are incentivized to keep making smartphones completely indispensable with payment features and passkeys for logins.

The Plan

I hope to leave my smartphone with my computer and use it more as a tool when needed. I’ve found myself mindlessly scrolling through youtube more often than I’d like to admit. I’ve been successful at a simple change, replacing my smartwatch with an analog quartz watch. The smart watch was not adding that much value and charging it everyday was a pain. Others also seem to be on this journey towards lesser distractions and mindfulness.

In this article I’ll focus on the cause from the perspective of Indian workers looking to immigrate to America via employment options. I am sympathetic to other immigration as well but have not studied those scenarios.

Current Green card backlog

Over 1.8 million cases are now estimated to be pending for employment-based green card processing. Green card allocation is capped based on country of birth. Because immigration in recent decades has been dominated by tech workers from India and China, they face the longest wait times for a green card. Without any change in the policies, new applicants for a major category of applicants (EB2 and EB3) face a timeline of over a 100 years for getting through the green card process. Read that again; new applicants to the green card process will die before they get a green card.

The green cards queue is based on a date called the priority date. The current priority date for India is Jan 1st 2011, which is over 12 years ago. During covid, priority dates progressed temporarily so that green cards were available for around a 8 year gap. However, going forward from the 2010s, the number of applications for Indians compared to other countries continues to increase drastically. Hence the expected wait time for green cards exponentially increases to over 100 years.

Many applicants for green cards start under the H1B visa program. That program is capped to a maximum of 6 years of work unless you get a immigration petition (i.e. i140 with the priority date) filed. However even getting to that phase now takes multiple years of processing times. The Perm process itself takes over 2 years to complete in 2023 because of processing delays with various government agencies.

If you’re lucky and get the i140 filed it is possible for a H1B holder to continue renewing their visa indefinitely. However that benefit has strings attached. You need to actively get your visa stamped at a US consulate which takes an immense amount of time and money. Travel outside the US becomes a burden since getting a visa stamped itself is backlogged. Maintaining an active job that sponsors the H1B visa is required throughout while you wait for years. That means that most visa holders prefer working for stable mid to large sized companies instead of startups which potentially have high rewards but are high risk. In fact during layoffs earlier this year, many Indians had to return to India because of loss of their visa. If you change employers you have to redo initial steps leading to more paperwork and bureaucracy.

Those who are trying to immigrate to the USA end up trying to maintain their jobs. They are severely limited in making long term decisions including financial, family or other categories. When your foundations of location are unstable, there is a fog over many actions. We’ve been in America for almost 15 years now and are still stuck in this limbo. The experience and monetary rewards we’ve gained for these years has been tremendous, but I’m not certain how long we intend to continue this struggle.

Opportunities for Indians

For individuals like me, there are many opportunities in India now. My company and many others offer good jobs with similar profiles with senior leadership roles. Skilled workers have been returning to India and hence the working culture in many companies is comparable and I should be able to build networks there. Taking care of aging parents can be solved easily by leaving to go back home. Arguably a tech salary in India should translate to the higher end of a middle class lifestyle compared to a very average lifestyle in the bay area.

For kids coming here for education or starting work I am not sure if moving to the USA is still viable. There is hope that the immigration policies will improve but we’ve been waiting for that for years. Given the current state of politics, reform feels impossible.

Other countries like Canada and Australia offer good immigration options and are potentially still valid options.

India itself is growing quickly and maturing as a major economy. Capital is going to continue to flow into India for the next few decades as the USA looks to de-risk from China. I still believe that India cannot still utilize its greatest resource - people - well enough. Systemic issues like corruption, education, mis-management are still a drain. However the situation is improving and the society is slowly but surely realizing its potential. In the long term, the Indian diaspora will help India since they are deeply connected benefiting all countries.

America’s crisis

America has many strengths as a global leader. It provides opportunities that are unmatched and unparalleled in research and technical know how. However it still needs skilled labor especially from places like India to help it maintain its position.

Short term thinking and vilification of the outsider has led to a political quagmire of inaction. Based on contributions by skilled immigrants I can argue that streamlining immigration is in fact in the national interest of the USA. Japan and other countries have not been open to immigrants leading to rapid aging of the population. American society is relatively open to immigrants and has been a fantastic place to live in. About 40% PhD students in the US are international students. The technological dominance of the country is what makes it competitive and drives growth for the rest of the population. Legal and illegal immigration are mixed but none are solved leading to a complete stalemate for all parties.

Sometimes I am shocked at how trivial the problem feels. With a population of around 340 million people, the US feels sparsely populated for its land area. Here is some more trivia, the US mainland is actually slightly smaller than the area of India, but India has a population of more than 1.4 billion people (4x higher). The US can easily absorb immigrants at higher rates and actually hire some of those people to automate the processes in immigration offices.

Behavioral scientists can probably model this; but practically I do not think anyone is going to die waiting for a green card… they are just not going to consider coming to the USA. In the long term unless resolved, this is America’s crisis.