DEV Community: Cesar Vega

The URL Shortener System Design Lie: What Prep Guides Hand-Wave (And what production actually needs)

Cesar Vega — Wed, 04 Nov 2026 13:17:56 +0000

Recently I've been reading about system design, and I stumbled upon one of the "easiest" and "most basic" interview questions in system design: "Design A URL Shortener"

I saw the problem in Alex Xu's book, systemDesignOne, algomaster, HelloInterview, etc... And I noticed that these resources tend to "handwave" a lot of depth, depth that a real interviewer will hone in on because we know many people use buzzwords without understanding the background.

The "handwaves"

1. NoSQL vs SQL

Something I consistently saw across these guides is the disregard for explaining why SQL or NoSQL. In some cases, the authors mention it on one line, and that's it:

"A better option is to store mapping in a relational database."

Other times, articles use the same substance-less justification:

"Given these points, a NoSQL database like DynamoDB or Cassandra is a better option due to their ability to efficiently handle billions of simple key-value lookups and provide high scalability and availability."

I see these consistently:

"As the URL mappings are independent and don't have complex relationships, a NoSQL database is a good fit. MongoDB is a strong candidate because:
It uses a leader-follower protocol, enabling the use of replicas for heavy read workloads.
MongoDB ensures atomicity in concurrent write operations and returns duplicate-key errors to prevent collisions.

I know the authors can't cover every topic, and many expect readers to know these concepts already. But this is a recipe for a candidate to stumble the moment someone questions these assumptions.

Interviewee: "We'll use NoSQL because it can handle billions of simple key-value lookups"

Interviewer: "Can't SQL handle simple key-value lookups?"

Interviewee: "Uhhhh, no?"

Most databases are already quite advanced, so either SQL or NoSQL will work for 99% of projects. For example, a Primary Key lookup in PostgreSQL (SELECT long_url FROM urls WHERE short_code = '2TX';) traverses a B-Tree index in memory in $O(\log N)$ time (3 to 4 pointer hops), resolving in under 1 millisecond—matching DynamoDB single-digit millisecond latency over TCP. We will also focus on that 1% of projects at massive scale where database choice matters.

So I intend to clarify the best database choice in depth for at least 3 scenarios: local scale, national scale, and global scale. And explain what actually matters when picking a database.

2. Single Point of Failure Crashes.

This is one of my biggest gripes because so many articles say a variation of "We have more than one database so we are good" or "the provider will handle this for us"

For example:

"Implement automated failover mechanisms for the API and data store layers to switch to backup servers in case of failure."

Or:

"Our core components (databases, caches, servers) support replication, which provides high availability and fault tolerance. The unique ID generation process also relies on a replicable database, which prevents a single point of failure."

And never mention this again. Or, even worse, don't mention single points of failure at all. This matters especially on smaller-scale systems: what if a single server or database handles all our traffic? - Which begets more questions like:

At what size should a new database or server be added?
- CPU saturation, connection limits, and blast radius dictate a new server. In production, scale out compute nodes once sustained CPU exceeds ~70% or active socket connections saturate thread pools. At the same time, databases add read replicas when read latency spikes and scale storage volumes vertically long before horizontal partitioning is ever warranted.
- For example, on Amazon RDS, the cost of CPUs/RAM of the database server is separate from the storage (e.g., SSD); each GB costs about $0.23 USD (Multi-AZ), so for pure data growth you'll find yourself increasing storage capacity rather than server capacity.
Can we get away with two tiny EC2 Amazon instances (t4g.nano)?
- Yes, for low-throughput workloads (like a few hundred to thousands of requests daily), two t4g.nano instances (0.5 GB RAM, 2 vCPUs) sitting across two Availability Zones behind an Application Load Balancer provide real high availability for negligible cost. The constraint on nano instances is not handling the traffic spikes—which burstable credits cover—but keeping the operating system and application memory footprint small enough to avoid Linux Out-Of-Memory (OOM) kills.
- One might confuse compute and storage here and think that having two instances is unnecessary if we are using a managed DB service (e.g., Amazon RDS) for two reasons:
- 1. Managed database services already include a "multi-availability zone" option, so it's easy to assume we don't need two compute instances for resilience.
- 2. The bulk of an instance's cost is CPU/RAM, not storage—so running multiple instances sounds like wasted money compared to a single instance with more storage capacity.
- But in reality, these are two separate layers: two t4g.nano EC2 instances across AZs provide high availability for the stateless compute tier (so our web app doesn't go down if one VM reboots), while an RDS Multi-AZ deployment provisions a second standby database instance in another AZ to provide high availability for the database tier.
Are Amazon instances already crash-resistant?
- No, individual EC2 instances are isolated virtual machines that can and do crash, terminate during underlying hardware faults, or lose transient host capacity.
Do Amazon EC2 instances already have memory attached?
- Every EC2 instance has virtualized RAM allocated by the hypervisor. Still, that memory is strictly volatile—the instant an instance crashes or restarts, all in-memory data is erased, which is why stateful persistence is offloaded to remote network storage (EBS) or managed database engines.

My goal is for readers to understand the nuances behind saying, "Put it all on DynamoDB and let it be."

3. How Is the Short URL Actually Made?

So far, I've found three main approaches to shorten the original URL; all are valid, but I've noticed guides skip details of each implementation.

3.1. The Hash and collision loop.

These look deceptively simple, and most articles have some variation of:

"To resolve hash collisions, we can recursively append a new predefined string until no more collisions are discovered."

Or:

"And truncated hashes collide: in 62^7 slots a collision becomes likely somewhere around a few million links, which you will pass on day one. You can check the table and retry, but now every create is a read plus a write, and the retry rate climbs as the table fills."

Or:

"If a collision occurs, we append a predefined string or salt to the long URL and hash it again until we find a unique key."

But what they omit is details about how hashing works - Imagine this:

Interviewee: "We can hash the long URL and get the first seven characters of the hash as our short URL"

Interviewer: "How would you prevent collisions between the first seven characters of the hash"

Interviewee: "I would append a predefined string or salt the long URL and hash it again"

Interviewer: "Would having a predefined string fix just one collision? What if you get more than two long URLs with the same seven characters? Would you also have to save in the database a list of salts?"

Interviewee: "Yes?"

The most important things to understand in this pattern are:

Hashes are non-reversible and are not compression. A cryptographic hash (like MD5 or SHA-256) doesn't compress a 300-character URL; So hashes in this case are just a way of generating a "random" string with alphanumeric characters - it's no different from generating a random string.
Collisions happen earlier than most people realize; for a seven-character short URL (3.5 TRILLION possible URLs), collisions start happening just after a few million generations (~2.35 million due to the Birthday Paradox).

3.2. The Over-Engineered "Key Generation Service" (KGS)

I don't think anyone in production should use something like this because it's complex and slow. It technically solves collisions, but it introduces a complex system that is hard to scale and manage.

Defenders of this implementation could argue for its generality, including things like a snowflake/Twitter ID generator. Still, those unique ID generators can't be used for short URLs if we want 7-8 characters because a 64-bit Snowflake ID is 19 digits in decimal, and converting that 64-bit integer to Base62 still requires 11 characters (If this doesn't make a lot of sense, that's okay; it will be explained soon).

A few examples of this implementation in online guides are:

"We can have a standalone Key Generation Service (KGS) that generates random six-letter strings beforehand and stores them in a database (let's call it key-DB). Whenever we want to shorten a URL, we'll take one of the pre-generated keys and use it. This approach makes things simple and fast. We also avoid encoding the URL, and we won't have to worry about duplicates or collisions. KGS will make sure all the keys inserted into key-DB are unique"

And then the same source handwaves the database overhead:

"Servers can use KGS to read/mark keys in the database. KGS can use two tables to store keys: one for unused keys, and one for all used keys. As soon as KGS gives keys to a server, it can move them to the used keys table. KGS can keep some keys in memory so it can provide them quickly whenever a server needs them. For simplicity, as soon as KGS loads some keys in memory, it can move them to the used keys table. This ensures each server gets unique keys. If KGS dies before assigning all the loaded keys, it can move them back to the used keys table."

This pattern also adds huge DB overhead by requiring synchronization between databases and continuously inserting, reading with locks, moving, and deleting rows.

KGS also handwaves the complexity of server crashes (availability) and multiple databases; for example, do we have separate databases for used and unused keys? Are they in the same database? What if one database crashes? How do we decide which database to send the data to then?

I've noticed candidates gravitate towards this solution when they want to design for large scale but lack specific knowledge of more streamlined patterns, like using Redis counters, which are single-threaded, or relying on MongoDB's internals; therefore, they can generate a count that will always be unique - we'll dive deeper into this later in the article.

3.3. The Counter + Base62: The Clean Math (And the Handwaved ID Generator)

This is my preferred solution. But I've noticed sites often leave out details that can make or break someone's mental model. Here are a couple of examples:

"Its INCR command atomically increments the Counter and returns the new value in a single operation. Because Redis is single-threaded, two simultaneous calls will always receive different values. If one gets 1000, the other gets 1001. This guarantee is what makes Redis ideal for distributed counter management. Each counter value is unique, eliminating the risk of collisions without the need for additional checks."

And:

"Challenges: In a distributed environment, maintaining a single global counter can be challenging due to synchronization issues. All instances of our Primary Server would need to agree on the counter value... Sequential counters also produce predictable short codes, making URL enumeration possible. An attacker could iterate through codes to discover all URLs."

If the candidate memorizes this information without understanding the background, they will fall into a trap like:

Hash vs Radix: Sometimes candidates think "Base62" is like a hash function, but it is actually a Radix function. Here are the differences between them:

Feature	Hash Function (e.g., SHA-256, MD5)	Base62 (Radix Representation)
What it is	A one-way mathematical function mapping variable-sized input to a fixed-size digest.	A positional base-conversion system using 62 alphanumeric characters (`0-9`, `a-z`, `A-Z`).
Primary Goal	Fingerprinting, integrity verification, or pseudo-random distribution.	High-density positional notation: representing large Base-10 integers using fewer characters.
Reversibility	Irreversible (one-way; original input cannot be computed back from the hash digest).	Fully Bijective (two-way; can be decoded back to the exact starting integer via modulo/quotient arithmetic).
Collision Risk	Present (different inputs can produce matching digests via the Birthday Paradox).	Zero (a unique input integer maps deterministically to a unique Base62 string).
Output Length	Fixed length (e.g., SHA-256 is always 256 bits / 64 hex characters regardless of input length).	Dynamic length (proportional to integer size: values $< 62^7$ fit within 7 characters).

Using a single-threaded counter without mentioning coordination when scaling, where the Counter lives, or what happens when your "counter server" crashes.
- In production, app servers don't call an external counter on every single write. They use dynamic range leases. It's like fetching a block of 1,000 IDs at a time with INCRBY 1000 from an atomic coordinator (like Redis) and dispensing them locally in memory. If an application server crashes, the remaining IDs in that leased range are abandoned; because a 7-character Base62 namespace has over 3.5 trillion possible values, discarding a few hundred numbers during a crash costs practically nothing and avoids complex recovery locks. Meanwhile, the coordinator survives restarts by replaying its on-disk write-ahead log (such as Redis AOF) or synchronizing across Multi-AZ replicas with a forced offset jump to avoid reissuing duplicate IDs.

Security fixes: Many articles mention how using a sequential unique counter creates security issues; yet none show how to fix this.
- The fix is to pass the integer counter through a reversible, collision-free permutation—such as a lightweight Feistel cipher or an obfuscation tool like Sqids/Hashids—before converting to Base62. This scrambles sequential numbers into deterministic, random-looking alphanumeric tokens without risking duplicate keys.
- Remember: The generated short URL doesn't need a direct relationship to the long URL. Your short URL doesn't need to include any information about the long URL; it just needs to be unique.

4. Redis Read-through/Write-through/Cache aside

When guides mention Redis, I've noticed many don't distinguish between Read-through/Write-through and cache-aside architectures. This distinction matters when discussing our system's trade-offs. Some examples I've seen:

"1. A user clicks a short URL link: https://tinyurl.com/zn9edcu

The load balancer forwards the request to web servers.

If a short URL is already in the cache, return the long URL directly.

If a short URL is not in the cache, fetch the long URL from the database. If it is not in the database, the user likely entered an invalid short URL.

The system returns the long URL to the user.

The example doesn't even mention whether we're using cache-aside or read-through/write-through architectures. It might describe cache-aside, but it leaves the reader guessing about the details—and notice how Step 4 fetches from the database and Step 5 returns it to the user without ever writing the URL back into the cache!

Or this other example:

"After receiving a request, a web server first checks if the cache has the available response. If it has, it sends data back to the client. If not, it queries the database, stores the response in cache, and sends it back to the client. This caching strategy is called a read-through cache"

This example is misleading; what it describes is actually the definition of Cache-Aside, not Read-Through. In a true Read-Through cache, the application server talks only to the cache layer. The cache engine itself owns the database driver, connects to PostgreSQL, and transparently pulls the record on a miss. In the real world, almost every production stack uses Cache-Aside because standard Redis has no database drivers or query logic to fetch data from PostgreSQL or DynamoDB on its own. Mislabeling Cache-Aside as Read-Through confuses candidates about who actually owns the database driver and SQL connection pool.

And:

"We can cache URLs that are frequently accessed. We can use some off-the-shelf solution like Memcached, which can store full URLs with their respective hashes. The application servers, before hitting backend storage, can quickly check if the cache has the desired URL."

These examples barely explain how the hardware works or how it fits into our architecture. Are these services (Redis/Memcached) added on their own instance? How are they provisioned? What happens if they crash? Does Redis sit between the server and database as a proxy, or alongside the server as an internal backing service? If the same Redis cluster handles both the read cache (with LRU eviction) and the atomic ID counter (INCR), what stops Redis from evicting your counter key when memory fills up? If Redis crashes, does your Counter reset to zero? - All of these questions will be answered properly when we write our own implementations for three different scales.

Guides also handwave what happens when you use Redis for counting and caching:

As an Ephemeral Cache (Reads): URLs are cached with an LRU (Least Recently Used) eviction policy to keep hot links in memory.
As an Atomic Counter (Writes): Redis executes INCR or INCRBY to hand out unique IDs for Base62 encoding.

Another crash could happen if you co-locate both roles on a single Redis instance configured with the standard allkeys-lru (least recently used) maxmemory policy, because servers lease counter blocks in chunks (e.g., fetching 1,000 IDs at a time). That counter key sits idle between leases. When read traffic surges and Redis memory fills up, Redis's LRU algorithm will see the idle counter key and evict it from RAM. To prevent Redis from evicting the Counter while running, change the configuration from allkeys-lru to volatile-lru (under volatile-lru, Redis evicts only keys with an explicit expiration time, leaving our non-expiring counter key untouched) and/or physically separate the instances. To ensure the Counter doesn't reset to zero if the Redis server crashes and reboots, we need an Append-Only File (AOF) saved to disk or replicated across Availability Zones.

5. Real sizes (Servers, databases).

System design prep guides frequently create world-scale scenarios, inflate traffic numbers, and jump to massive abstract scales:

"Because of the massive scale of billions of records, we must shard our database across multiple database servers using consistent hashing on the short URL."

Or even examples like:

"Since we expect to have 500M new URLs every month and we would like to save this data for 5 years:
Total number of URLs: 500M * 5 years * 12 months = 30 billion
Total storage: 30 billion * 500 bytes = 15 TB"

"To scale out our DB, we need to partition it so that it can store information about billions of URLs. We need to come up with a partitioning scheme that would divide and store our data into different DB servers."

These examples usually defend themselves by saying, "The cloud will handle it." Still, it's important to know how much servers actually cost, how much capacity they have, and how they differ.

For instance, some guides calculate 15 TB for 30 billion URLs and claim we must partition across different DB servers. But in real-world infrastructure, a single standard AWS RDS PostgreSQL instance can attach up to 64 TB of storage on a single volume, and an Amazon Aurora cluster scales up to 128 TB automatically without sharding. 15 TB easily fits inside a single managed instance. At the same time, relying on a standalone, un-replicated database instance on a single server without synchronous replication or automated failover remains a catastrophic Single Point of Failure.

Or what if you need a small, internal system? A single db.t4g.micro instance (with 1 GB of RAM and a baseline 20 GB gp3 SSD) and a t4g.nano server are more than enough, yet if that DB or server crashes, your whole system has multiple single points of failure. Imagine a scenario like this:

Interviewee: "So one single instance would be enough for this small-scale operation"

Interviewer: "So how would you handle redundancy? What would happen if that instance fails?"

Interviewee: "The cloud will handle it?"

Many guides also gloss over provisioning. When we provision a managed cloud database like AWS RDS (db.t4g.micro), we're renting an isolated virtual machine. If we run it as a Single-AZ (Availability Zone) instance, we still have a Single Point of Failure, so to make it resilient, we need to enable Multi-AZ (which provisions a synchronous hot standby in a different data center that automatically takes over if the primary dies). The problem is that guides often overlook the internals of this mechanism, and candidates often treat it as a magic phrase without realizing it solves failover resiliency, not write-throughput scaling.

Candidates often have warped mental models about the physical reality of the servers. For example, Redis persistence doesn't work the same across bare metal and cloud providers. On a self-hosted Linux machine, Redis logs transactions directly to /var/lib/redis/appendonly.aof on an attached SSD.

However, on burstable managed cloud instances like AWS ElastiCache (cache.t4g.micro), AWS turns off continuous AOF disk logging because constant disk syncing (fsync) exhausts shared I/O credits and blocks the single-threaded event loop.

Note: Burstable instances and I/O credits
A burstable instance operates on an allowance: you get a modest baseline of CPU capacity (around 10%–20%) when idle, but you accumulate credits that let you burst up to 100% CPU when sudden traffic arrives.

The issue is that storage operations follow a similar metering model. When you run an Append-Only File (AOF), every URL creation triggers an INCR command, which forces an fsync() to physically write those bytes from the operating system's buffer to disk. On a tiny, multi-tenant cloud instance, continuous fsync() calls burn through your allocated I/O credits almost immediately. Once those credits drain to zero, disk access is throttled, causing writes that usually take under a millisecond to stall for 50–100ms. Because Redis executes all commands on a single thread, waiting on that throttled disk blocks the entire engine—freezing reads, writes, and all incoming network connections.

So instead of writing an on-disk transaction log, managed micro instances rely on network-level durability: the primary node asynchronously streams memory state to a hot replica in a different Availability Zone, while periodic binary snapshots (RDB files) are pushed to durable Amazon S3 storage for disaster recovery.

Something else I've noticed is that guides tend to handwave about scaling a system progressively. If we are going to need 15 TB or 36 TB of data in 5 years, we shouldn't architect Day 1 for Year 5; we can size this for 12-24 months and then scale upwards if needed.

I believe it's important to ground QPS/TPS/storage values in real offerings. That way, it's much easier to build a complete mental model.

6. Load Balancer vs. API Gateway vs. Reverse Proxy

I've noticed that many guides also use Load Balancers, API Gateways, and Reverse Proxies interchangeably. For example:

"The load balancer distributes incoming client requests across multiple servers to prevent any single server from becoming a bottleneck. The load balancer can be configured with routing algorithms such as round-robin, least connections, or IP hash."

While another guide ignores the load balancer completely and shows a diagram like this:

[ Client ] ──► [ API Gateway ] ──► [ URL Service ] ──► [ Database ]

Guides should be clear about this instead of glossing over it. In a real system, we might need both an API Gateway and a load balancer, or just one, depending on our architecture. Much of the confusion comes from these two being bundled together in modern managed offerings—such as cloud ingress controllers (like Azure Application Gateway Ingress Controller or GKE Ingress) that handle external Layer 7 (HTTP/HTTPS) traffic routing, TLS termination, and load balancing in a single layer.

Even when bundled, an API Gateway and a Load Balancer are not interchangeable. The confusion stems from the fact that both API Gateways and Load Balancers are reverse proxies:

A Load Balancer is a reverse proxy tuned for raw connection throughput and even traffic spreading. It is lightweight and consumes very few resources. Load balancers can also be confusing because they behave differently depending on which network layer they operate at:
- Layer 4 (Network Load Balancer): Looks only at IP packets and TCP/UDP ports. It has no concept of HTTP, meaning it cannot see URL paths, headers, or request lines.
- Layer 7 (Application Load Balancer): Parses HTTP/HTTPS request lines, headers, cookies, and paths (e.g., routing /api/* to Target Group A and /* to Target Group B). However, it stops short of evaluating application-level business policy like JWT auth verification or user-specific rate limits. Because of this path routing, an ALB feels very close to an API Gateway.
An API Gateway is a reverse proxy tuned for Layer 7 application policy (authentication, granular rate limiting, and route rewriting). It uses significantly more computational power to inspect payloads, validate cryptographic tokens, and enforce business rules.

Another confusing point is that an API Gateway can technically serve as a Load Balancer. Many API Gateways (such as Kong, Envoy, or NGINX) let you configure upstream load-balancing algorithms like Round Robin or Least Connections across your backend instances.

To make things more complex, Load Balancers can sit either "before" or "after" an API Gateway depending on how the system is set up:

The High-Scale / Kubernetes Setup (Load Balancer BEFORE Gateway):

If you run gateway software like Envoy or Kong yourself, you need multiple gateway servers so the gateway itself doesn't crash or become a bottleneck. But how do internet users reach multiple gateway servers? You put a Layer 4 Network Load Balancer (NLB) in front to balance incoming TCP sockets across your gateway fleet.

The Standalone Gateway (No External Load Balancer):

In smaller setups, or when using cloud-managed serverless gateways (like AWS API Gateway), you don't provision a separate load balancer in front of it. AWS API Gateway already has an internal ingress routing fleet built in. You point your custom domain name directly to API Gateway, and it routes requests to your backend microservices or serverless functions.

Zero API Gateways (Load Balancer Only):

If you are building a simple service that doesn't need API token tiers, client rate limits, or complex route rewrites, an Application Load Balancer (ALB) can terminate TLS (decrypting incoming HTTPS traffic) and use Round Robin to distribute HTTP requests straight to your compute nodes. The backend servers handle authentication and business logic themselves.

So we can think of these three in an inheritance hierarchy:

Reverse Proxy: Any server that sits between a client and a backend server, intercepting requests and responses so the backend stays hidden from the outside world.
Load Balancer (Reverse Proxy + Distribution): A reverse proxy optimized to monitor backend health and spread traffic evenly. A Layer 4 LB inspects only raw TCP packets, while a Layer 7 LB inspects HTTP request lines and paths. Both offer ultra-low latency and consume minimal compute. It can send requests to an API Gateway fleet or directly to backend servers.
API Gateway (Reverse Proxy + Load Balancer + Governance): A specialized reverse proxy that does load distribution, but also inspects HTTP headers and payloads to enforce business rules—blocking unauthenticated callers, rejecting spam via token buckets, and rewriting URL paths before application code ever executes. Because it decrypts bearer tokens, parses request bodies, and validates schemas, it uses more compute and can introduce a slight latency penalty. It typically sends requests directly to backend servers, though in complex multi-tier setups it can route through internal load balancers.

7. Consistent hashing

Whenever system design articles discuss scaling past a single machine, they mention consistent hashing:

"Our design is horizontally scalable. The database can be sharded, and we can use consistent hashing to distribute load across both the application and database servers evenly."

"The additional data store is partitioned using consistent hashing. The partition key is the long URL, so we can quickly find the URL record. A key-value store such as DynamoDB is used as the additional data store."

Or fall back on basic modulo arithmetic:

"We should also potentially consider sharding the database. We can shard it using some mapping from the URL (for example, the URL's hash code modulo some integer), which will allow us to locate the database which contains this file quickly."

Modulo hashing (hash(key) % N) is an anti-pattern for dynamic systems (which most systems are): the moment you add or remove a single server, almost 100% of your keys map to entirely different machines, causing data thrashing or thundering herds. Consistent hashing solves this by ensuring that when a node joins or leaves, only a fraction of keys ($K/N$) get remapped.

The problem is how guides illustrate it: a cosmic 360-degree circle floating in the middle of a whiteboard diagram, with keys and servers casually "mapped onto the ring."

[ Application Servers ] ──► ( The Floating Hash Ring ) ──► [ Database Shards ]

This abstraction can lead to blind spots when an interviewer digs into the physical implementation:

1. Where Does the Ring Physically Live?

Candidates often assume the hash ring is a standalone service or a central coordinator machine. But if 50 application servers have to make a network call to a "Hash Ring Coordinator" on every single request, that coordinator becomes a latency bottleneck and a single point of failure.

In production, there is no ring server. The hash ring is an in-memory data structure (like a TreeMap<Long, Node>) living directly inside the local process RAM of the server making the routing call to the database.

When a server needs to route a short URL:

It hashes the key using a fast, non-cryptographic algorithm like MurmurHash3 on its own CPU.
It executes a local binary search in $O(\log N)$ time to find the nearest server pin.
The lookup finishes in under a microsecond with zero network round-trips.

2. How Do Servers Coordinate Changes?

If every application server keeps its own copy of the ring in local RAM, how do they stay synchronized when a database shard crashes or a new cache node boots up?

Production architectures solve this through two distinct models:

Centralized Coordination:

In systems using standalone cache pools (like Memcached) or sharded SQL instances, the storage nodes don't talk to each other. Instead, a small, independent cluster of coordinator machines (e.g., t4g.small instances running etcd, Consul, or ZooKeeper) continuously pings the storage nodes. Application servers keep an open watch listener with this coordinator fleet. When a storage machine drops offline, the coordinator alerts the application servers, which instantly recompute and swap their local in-memory tree pointers to route around the dead node.

Decentralized Gossip:

Distributed databases like Apache Cassandra or Amazon DynamoDB eliminate external coordinator servers. Each database server maintains the hash ring directly in process memory. The database machines continuously ping each other across an internal network port to exchange health updates ("Gossip"). If Database Machine C dies, Database Machines A and B detect the dropped heartbeat, spread the update cluster-wide, and independently adjust their local partition boundaries without needing an external manager.

3. Can Load Balancers and API Gateways Use Consistent Hashing?

Guides suggest using consistent hashing to "distribute load across both application and database servers." This creates confusion: should our Load Balancers or API Gateways use consistent hashing to distribute requests to stateless backend servers?

For a stateless URL shortener - absolutely not.

An Application Load Balancer's job is fair load distribution. Algorithms like Round Robin or Least Outstanding Requests spread traffic evenly across all web servers.
If your Load Balancer consistently hashes incoming requests based on the URL path (GET /popular-deal), 100% of the traffic for that viral link will hammer the same backend server. That node will burn through CPU and crash while the remaining servers sit idle. Because stateless backend nodes read from a shared Redis cache or database cluster anyway, pinning specific URLs to specific app servers creates hot spots with no performance gain.

Consistent hashing at the Gateway or Load Balancer tier makes sense only when the upstream servers hold in-memory, non-shared state:

Local In-Memory Cache Tiers: If backend compute nodes maintain an LRU cache directly inside their own process memory instead of calling an external Redis instance, consistent hashing ensures repeat requests hit the host that already holds the cached data.
Stateful WebSockets: Real-time chat applications (like Discord) use consistent hashing at the gateway to route users to the exact server hosting their active room connection.
Layer 4 Packet Balancing (e.g., Google Maglev): Specialized edge load balancers use consistent hashing algorithms across router fleets so that network packet routes remain stable even if intermediate proxy boxes restart.

Unless your compute nodes hold local state, consistent hashing belongs on the data-routing clients targeting partitioned caches or database shards, not on the front door distributing traffic across stateless application instances.

Next steps

Now that we have seen the many holes that guides tend to have, the next part of this article series will show how to design a URL shortener without leaving out any details. This way, any candidate asked this question will be prepared to go in depth at any point in their interview.

FAQ

Implementation · Will the next article provide concrete code or architecture diagrams?

Yes. Part 2 provides production VPC topologies and runnable code across three distinct tiers:

Small Internal MVP (~500 writes/day): Multi-AZ PostgreSQL using native BIGINT GENERATED ALWAYS AS IDENTITY sequences, an Application Load Balancer, and a micro Redis instance for Cache-Aside reads.
National Consumer Scale (~5,000 writes/sec): Horizontally autoscaling app clusters, dedicated Redis clusters separating atomic ID range leases from LRU read caches, and read replicas for uncached lookups.
Global Scale (100M+ writes/day): Multi-region edge ingestion, decentralized token leases, and auto-partitioned storage (DynamoDB Global Tables).

Trade-offs · How do I actually defend SQL vs. NoSQL in an interview?

Do not recite the generic textbook claim that "NoSQL is faster for key-value lookups". In memory, a PostgreSQL primary key lookup traverses a B-Tree index in $O(\log N)$ time (3 to 4 pointer hops) and resolves in under 1 millisecond—matching DynamoDB latency over TCP. Base your defense on two concrete physical factors:

Write Idempotency (Deduplication): If shortening an identical long URL twice must return the same short code, SQL guarantees this natively via an atomic UNIQUE constraint on long_url. In a NoSQL table partitioned by short_url, querying by long_url requires either a catastrophic full-table scan or an asynchronously replicated Global Secondary Index (GSI). Because GSIs are eventually consistent, concurrent writes for the same link create duplicate short codes.
Single-Writer Ceilings: A single properly tuned relational database instance comfortably handles 10,000 to 20,000 indexed inserts per second and up to 64–128 TB of storage. Choose NoSQL (DynamoDB or Cassandra) only when sustained write throughput exceeds what a single primary can physically commit (30,000–50,000+ writes/sec) and you treat every link generation as a blind append without global deduplication.

Failure Handling · What happens during a cloud database failover?

Availability is preserved by isolating failure domains rather than assuming managed cloud services eliminate downtime:

The 30–60s Failover Window: If a Multi-AZ primary database crashes, automated DNS failover repoints traffic to the synchronous standby in 30 to 60 seconds. During this window, link creation (POST /shorten) fails, but link redirects (GET /{code}) continue resolving uninterrupted from the Redis Cache-Aside tier.
Circuit Breakers: Application servers must set aggressive socket timeouts and trip circuit breakers on database calls. If Redis misses a cold link during a database outage, the server must fail fast rather than hanging on dead database TCP connections and exhausting worker thread pools.
Counter Recovery: Application servers lease blocks of IDs (e.g., INCRBY 1000) and treat remaining local tokens as ephemeral. If an app server crashes, discard its leased block. Discarding a few hundred IDs out of a 3.5-trillion Base62 namespace costs nothing and avoids complex distributed recovery locks.

Security · How do I prevent sequential ID enumeration?

Base62 is a positional base conversion, not encryption—incrementing an integer counter directly leaks predictable URLs (/1, /2, /3) that scrapers can iterate over.

Reversible Obfuscation: Pass the 64-bit integer through a lightweight, collision-free Feistel cipher or permutation tool (like Sqids/Hashids) before encoding to Base62. This scrambles sequential increments into pseudo-random alphanumeric tokens without risking collisions.
Edge Rate Limiting & 404 Heuristics: Enforce sliding-window rate limits at your API Gateway or reverse proxy (e.g., 60 lookups/min per IP). Track 404-to-200 response ratios at the WAF; clients scanning non-existent short codes will hit abnormal miss ratios and can be automatically blocked at the perimeter.
HMAC Signatures for Sensitive Links: For private or single-use URLs (such as password resets or invoices), append a cryptographic signature token (/xK9b?sig=...) validated at the gateway before redirecting.

Scaling · When should I actually shard a database?

Never shard simply because an article mentions "billions of rows". 1 billion URLs at 500 bytes per row is only 500 GB, and 30 billion URLs is 15 TB—both fit comfortably on a single standard 64 TB AWS RDS volume or a 128 TB Aurora cluster without manual partitioning. Shard only when physical single-node thresholds break:

Write IOPS & WAL Flush Limits: When sustained write volume breaches ~20,000 to 40,000 writes/sec, where single-primary disk locks and write-ahead log (WAL) syncs become the hardware bottleneck.
Multi-Region Latency & Edge Distribution: When global users face 150ms+ cross-continental redirect latencies. Resolve this by deploying edge reverse proxies (Cloudflare/CloudFront) and multi-region read replicas (like Aurora Global Database) before attempting cross-region sharding.

About the author:

I'm a full-stack (frontend-leaning) Senior / Staff engineer. I'm currently exploring new engineering opportunities. If your team is tackling distributed systems challenges or needs someone who designs for production reality instead of interview buzzwords, connect with me on LinkedIn or check out my work on GitHub.

Skills, MCPs, and Commands are the same context engineering trend.

Cesar Vega — Thu, 20 Nov 2025 21:54:01 +0000

What are skills:

Skills are folders of instructions and scripts that Claude loads to do specialized tasks. The point of skills is to make Claude follow guidelines and be more deterministic.

Benefits.

More deterministic
Easy to edit, share, and set up.
Efficient context use.*

Make AI more deterministic.

This is one of the biggest issues with LLMs right now: they spout a lot of code, and they can and will come up with two different approaches and answers to the same prompt. With skills, we add guardrails, instructions, and scripts that tell the LLM exactly what to do. For example, the playwright-skill I downloaded has a helpers.js file which has a bunch of scripts like launchBrowser or safeClick, so Claude can use those functions and the result will always be the same.
* This was also a benefit that MCPs had.

Easy to edit.

Since Skills are just .md files and scripts, they are really easy to edit and share if necessary. The downside is that the files can be hard to maintain if they don't have a single source of truth.

Context

Understanding Claude context

Running /context in Claude code (And in most other CLIs) gives you a breakdown of how context is used in the CLI:

The context is divided into:

System prompt: The instructions set that defines Claude's identity, behavior, and core operational guidelines
- Skills are loaded here.
System tools: Built-in capabilities available in every conversation (file operations, execution, web access, agents).
MCP tools: MCP tools and descriptions of each tool.
Memory files: Project-specific context files (like CLAUDE.md) that provide persistent knowledge about your projects and preferences.
Messages: The actual conversation history between you and Claude in the current session.
Free space: Available context window capacity for additional content.
Autocompact buffer: Reserved space that triggers automatic context compression when filled to prevent overflow.

Skills context

Claude's path when using skills works like this:

At the start of a session, Claude scans all available skill files and reads a short explanation for each one from the frontmatter YAML in the Markdown file - this is very token efficient: each skill only takes up a few dozen extra tokens, with the full details only loaded in should the user request a task that the skill can help solve.

For example, at the very beginning of each session, Claude generates a system context file. In which skills are loaded in a section like this:

   <available_skills>
     <skill>
       <name>analyzing-financial-statements</name>
       <description>This skill calculates key financial ratios and metrics from financial statement data for investment analysis
  (project)</description>
       <location>managed</location>
     </skill>
     <skill>
       <name>example-skill</name>
       <description>Demonstrates the basic structure of a Claude Skill. Use this as a template when creating new skills. (project)</description>
       <location>managed</location>
     </skill>
     <skill>
       <name>playwright-skill</name>
       <description>Complete browser automation with Playwright. Auto-detects dev servers, writes clean test scripts to /tmp. Test pages, fill forms,
  take screenshots, check responsive design, validate UX, test login flows, check links, automate any browser task. Use when user wants to test
  websites, automate browser interactions, validate web functionality, or perform any browser-based testing. (project)</description>
       <location>managed</location>
     </skill>
   </available_skills>

You can see an example of the whole prompts at leaked prompts at ageirtj's repo

All my skills take approximately 200-250 tokens (including XML tags, descriptions, and metadata). The actual descriptions alone (just the text content) would be 35~40 tokens total.

Claude only loads the .yaml-like description and data at the top of the document, and from there it decides if it's worth reading more (Progressive Disclosure):

NOTE: Skills depend on a coding environment

One thing to note is that the skills mechanism is entirely dependent on the model having access to a filesystem, tools to navigate it, and the ability to execute commands in that environment. The filesystem is your computer, and it can change things in YOUR computer. So you should always verify whether your functions or commands have side effects that could affect your system.

This can also be beneficial because you are not dealing with external dependencies, but it brings back the "It works in my computer" problem.

Skills vs MCP

I mentioned that skills are not FULLY loaded upfront; they load the basic description, and then the agent decides whether it's worth reading more. MCPs used to be designed (And some still are) in a way that all of their tools were loaded up front, taking a lot of context. But new MCPs are improving their architecture, and they are using the same patterns as Skills to have separate code execution, which brings their context size to similar levels as Skills.

Note: Technically, you can use scripts in skills and avoid MCPs. (And vice-versa)
You can use both together: MCP connections give Claude access to tools, while Skills teach Claude how to use those tools effectively.
MCP connects Claude to external services and data sources. Skills provide instructions for how to complete specific workflows.

Skills PROS:

Skills are simple: The core simplicity of the skills design is why I'm so excited about it. MCP is a whole protocol specification, covering hosts, clients, servers, resources, prompts, tools, sampling, roots, elicitation, and three different transports (stdio, streamable HTTP, and originally SSE). Skills are Markdown with a tiny bit of YAML metadata and some optional scripts in whatever you can make executable in the environment.
Skills are stable: Since skills are just .md files with scripts, they are usually very stable and simple to maintain.

MCP PROS:

Can connect to external applications: This is the biggest pro in my opinion; If you want an API-like interface that can connect to other applications, this is the way to go, especially since there are many officially supported MCPs from big organizations like Linear/Slack/Stripe. You can also benefit from MCP servers that run the code in the owner's cloud instead of locally.

Things to consider that I didn't delve into:

Reliability, security/isolation, cross-device availability, latency, required runtime permissions, collaboration features, etc...

Plawright MCP vs skill example.

DISCLAIMER: It's not the same maintainer, so some of the features in the MCP are not in the SKILL and vice versa.
The Playwright skill uses around 100 tokens in context, while the MCP uses ONE HUNDRED times more (10'000 tokens). The main difference is that the Skill has a lot of the functionality the MCP has, but it gets loaded ONLY when it's necessary, while the MCP is always in memory.

Here is a breakdown of the approximate token use that Playwrite MCP uses:

  Based on the JSON schema definitions visible to me, here's a rough estimate:

  Simple tools (minimal parameters):
  - browser_close, browser_navigate_back, browser_install, browser_console_messages
  - ~150-250 tokens each

  Medium tools (moderate parameters):
  - browser_resize, browser_navigate, browser_press_key, browser_take_screenshot, browser_wait_for, browser_tabs
  - ~300-500 tokens each

  Complex tools (extensive parameters with nested schemas):
  - browser_evaluate, browser_fill_form, browser_click, browser_type, browser_drag, browser_hover, browser_select_option, browser_run_code
  - ~500-800 tokens each

  Rough total estimate: 8,000-10,000 tokens for all 22 Playwright MCP tools, including their full JSON schema definitions, descriptions, and parameters
  specifications, and metadata.

I will say this again, 10'000 tokens in context for something we might not use is not worth it. I have personally disabled the Playwright MCP, but I had to change the Skill a bit to fit my work better (which is waay easier to do in Skills, since I have the files right there in my codebase).

Semi-outdated MCP criticisms (In my opinion):

I saw this quote by Simon Willson, but I think the main point about spending tokens can be mitigated by good MCP design:
* "My own interest in MCPs has waned ever since I started taking coding agents seriously. Almost everything I might achieve with an MCP can be handled by a CLI tool instead. LLMs know how to call cli-tool --help, which means you don't have to spend many tokens describing how to use them—the model can figure it out later when it needs to."
* My comment about this is that there is a new trend with MCPs that do the same as Skills, they display a short description and then point to relevant files and scripts to be used. - But note: For most tasks, it's probably still better to use Skills.
- https://www.anthropic.com/engineering/code-execution-with-mcp

What about RAG?

RAG is a concept that was very hyped before, and it's still relevant. RAG is a middle step where the agent searches and retrieves external data with whatever tools are available to it - grep, vector database, or any relevancy algorithm.

It can be similar to Skills or MCPs in the way that it's a tool that an LLM can use to improve its answer.

What about Claude commands?

Custom slash commands allow you to define frequently-used prompts as Markdown files that Claude Code can execute. There are plenty of pre-loaded commands in Claude code like /context, /mcp, /github, etc...
They behave almost the same as skills in the way that they are some kind of script or prompt that the LLM runs when you tell it to.

It seems that commands haven't gained a lot of traction, and I think it's because they tend to be focused on small changes. I think of Skills as an orchestrator of commands. If a command is a single function or bash, skills are a group of functions or commands.

Understanding that context is stateless,

We pass the whole conversation every time
One thing that really helped me understand why keeping context clean is important is that LLMs are stateless; in every new message, we are just passing the whole conversation back and forth to the model (Maybe some providers optimize for this?). So every new message ends up being your whole conversation and the latest message attached to it.

Sending a single-line message at the end of a 400-line discussion with a lot of back-and-forth is a lot different than sending one at the end of a 100-line structured discussion. MCPs and Skills can help us keep this context as small as possible and even save their thoughts in concise documents that we can reference in a new chat with an LLM.

Conclusion

Claude, it's becoming a general agent, an orchestrator. Skills, Commands, MCPs, and Agents make this explicit. And we as developers will have to focus a lot more on managing Context and providing guardrails, scripts, and instructions to restrict the LLM when necessary and let it work in what it does best.

Even when models are pushing context windows of 1 million tokens, they still struggle to keep track of things we have done in long conversations, so keeping things understandable and documented is still critical.

Feel free to send me sources and comments about this.

Sources:

https://support.claude.com/en/articles/12512176-what-are-skills
https://simonwillison.net/2025/Oct/16/claude-skills/
https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
https://github.com/lackeyjb/playwright-skill?tab=readme-ov-file
https://news.ycombinator.com/item?id=45619537

https://github.com/asgeirtj/system_prompts_leaks/blob/main/Anthropic/claude-4.5-sonnet.md
https://www.anthropic.com/engineering/code-execution-with-mcp
https://aws.amazon.com/what-is/retrieval-augmented-generation/
https://code.claude.com/docs/en/slash-commands
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

In Cursor, Context is King.

Cesar Vega — Sat, 05 Jul 2025 17:07:15 +0000

Executive summary

If there is one thing you should take away from this document, it is to "Document what you are doing in a separate file."
If you have time for a second thing, it is "Add context manually."

Understanding Context.

Context window

First, what is a context window? And how does it relate to effectively coding with Cursor?

A context window is all the context an LLM has when answering a prompt.

In Cursor, "context" is the information that is provided to the model. There are two types of context:

Intent context defines what the user wants to get out of the model. For example, a system prompt usually serves as high-level instructions for how the user wants the model to behave. Most of the "prompting" done in Cursor is intent context. "Turn that button from blue to green" is an example of stated intent; it is prescriptive.
State context describes the state of the current world. Providing Cursor with error messages, console logs, images, and chunks of code are examples of context related to state. It is descriptive, not prescriptive.

Providing context to Cursor.

When answering a prompt, Cursor will try to find context by itself, it does this with a proprietary model that pulls in the parts of your codebase that the model estimates are relevant, such as the current file, semantically-similar patterns in other files, and other information from your session. It also might use "tools" and MCPs like web search to find relevant context.

This proprietary model is pretty good, but it falls short when dealing with complex problems.

I made an experiment to show this. The experiment is a variation of the "Needle in the haystack" test. In this test I placed a riddle in our code, and asked Cursor to solve it.

Context experiment

The experiment consisted of a riddle that added a .txt file of 25k characters ~ 6k tokens with random text, and a riddle inside the random text. In this case, the riddle was a Caesar cipher with the key at the end of the file.

If anyone wants to see the whole experiment, please comment or DM me.

The results of the experiment were:

* Gemini 2.5 pro
 - Finds the file correctly ❌
 - Gets the answer correct. ❌

* Claude 4.0 sonnet
 - Finds the files correctly ✅
 - Gets the answer right. ✅

As we see, even with only a 6k context window, the Gemini model can't figure out the answer to the riddle. (6k tokens is about ~850 lines of code, 4 characters =~ 1 token).

I haven't confirmed, but I am sure that if I made the puzzle more intricate by adding text and more cross-references, the model would break

This is relevant because imagine Cursor looking for how to answer your prompt in the best way possible, it will look online, it will look at all your files, but it won't read them UNLESS you pass the file into context. (You can test this by seeing how many tokens are passed if you use a custom API token in Cursor)

How much context do we have?

In Cursor; Gemini, and Claude have 120k tokens for context. That might seem like a lot, but remember our experiment with 6k context? The models could degrade with way shorter contexts.

Here is the context of a few things for anyone interested:

Average stack overflow page call ~15k tokens.
The code files in a mid-sized company are at least a few million characters, which is at least 0.75 Million Tokens
- Average characters per file is about 4,721 characters ~= 1k tokens.
- Large files for an average company are ~= 30k characters ~= 8k tokens.

How Cursor handles a prompt.

This is how the Cursor handles a prompt:

You write your prompt and add your context. Then press enter.
Cursor uses it's proprietary model to analyze your prompt and context. You haven't hit the AI model yet (Gemini, Claude, etc...)
- There is no official documentation that says this directly, but there are allusions to it in Cursor official docs, and in Anthropic's system prompt docs. (And the leaked system prompt from Anthropic around May 2025).
  - Cursor prompts some tools with a proprietary LLM or algorithm to decide what MCPs to use.
Cursor takes the context you added, AND it takes what it thinks is the relevant context and appends it to the api.
- Cursor also adds a small system prompt (can't find official docs. But cursor adds about ~1k tokens to all your requests. I assume those are its custom instructions.)
The API/LLM then processes the prompt, and you receive the answer.

How to improve my prompts? - Keep track of your decisions in a document.

Finally, the good part. Here is what to do if you want to significantly improve the context that you send Cursor:

Make one or two documents depending on how big is your task, I usually call it "PLAN.md" and/or "TASKS.md"
Write down the problem, objective, insights and thoughts you have, and a plan on "PLAN.md", you can use AI to help you write the plan. It's usually useful to ask AI to write a plan with "atomic" steps, so it gives you small steps to follow.
Start working on the problem, every time you make progess (progress might be a new insight, a new piece of code, etc...), write down what you did on "TASKS.md", it's even better if you can reference what you did at "PLAN.md" too. Then commit.
Keep going. Remember to write new insights, failed attempts, and sources too in your documents. This development loop forces two things.
- You will think more about what you are doing, which is a lot of help as a developer.
- The AI will keep close track of context, and you can easily revert and correct if it goes off track. The AI will also be way better at problem-solving.

How to organize your project's folders - A quick guide to repository and folder structures.

Cesar Vega — Sun, 15 Oct 2023 15:49:17 +0000

Depending on your objectives and needs, there are many ways of organizing a project in React. But some patterns are considered best practices; here, I'll explain a few.

Atomic Design.

Atomic Design is a concept introduced by Brad Frost, and it's a methodology to build consistent and reusable design systems, especially in web interfaces.

Atoms

Atoms are the basic building blocks in this methodology. They're the smallest possible components, like form labels, buttons, inputs, or even design tokens such as colors, fonts, etc. Atoms can be abstract and don't necessarily represent the final product, but they help to create a consistent interface and development process.

Molecules

Molecules are combinations of two or more atoms that form relatively simple components together. An example could be a form label, a text input, and a button combined to make a search form. While atoms can exist in isolation (like a button), molecules find their true meaning when used in conjunction.

Organisms.

Organisms are relatively complex UI components composed of groups of molecules (and possibly atoms). Examples might include the header of a website with a logo (atom), a navigation menu (molecule), and a search form (molecule). Organisms provide context for the molecules and demonstrate how molecules can work together.

/src
  /components
    /atoms
      Button.jsx
      Icon.jsx
      ...
    /molecules
      FormInput.jsx
      UserAvatar.jsx
      ...
    /organisms
      Header.jsx
      Sidebar.jsx
      ...
    /templates
      MainLayout.jsx
      UserLayout.jsx
      ...
    /pages
      HomePage.jsx
      UserProfilePage.jsx
      ...

By feature or Domain.

This structure is popular for large projects. Here, we group components by the feature they relate to

/src
  /components
    /Button
      Button.jsx
      Button.test.jsx
      Button.css
    /Modal
      Modal.jsx
      Modal.test.jsx
      Modal.css
  /features
    /Todo
      /components
        TodoList.jsx
        TodoItem.jsx
      TodoActions.js
      TodoReducer.js
    /User
      /components
        UserProfile.jsx
        UserSettings.jsx
      UserActions.js
      UserReducer.js

By File Type

In smaller projects or applications with many shared components, it might make sense to group files by their type.

/src
  /components
    Button.jsx
    Modal.jsx
    ...
  /containers
    TodoContainer.jsx
    UserContainer.jsx
    ...
  /actions
    TodoActions.js
    UserActions.js
    ...
  /reducers
    TodoReducer.js
    UserReducer.js
    ...
  /styles
    Button.css
    Modal.css
    ...

Domain-driven Design (DDD)

For projects that closely align with domain-driven Design, you might structure your folders around aggregates, entities, and value objects.

/src
  /User
    UserAggregate.js
    UserEntity.js
    UsernameValue.js
    ...
  /Product
    ProductAggregate.js
    ProductEntity.js
    PriceValue.js
    ...

Modules or Packages

Modules are self-contained units of code that encapsulate a specific functionality or feature, often used in mono repo structures or when scaling with multiple teams.

/src
  /modules
    /Todo
      TodoView.jsx
      TodoLogic.js
      TodoService.js
      ...
    /User
      UserView.jsx
      UserLogic.js
      UserService.js
      ...

Conclusions

The takeaway is to keep your structure simple. It should be intuitive for developers to know where to place their files and easy for them to be consistent.
I showed a few common structures in this article, but feel free to use what fits your team.

Job hunting in Canada. (And tips for recent immigrants)

Cesar Vega — Sat, 07 Oct 2023 15:46:40 +0000

I got laid off at the beginning of September 2023. And I was lucky enough to get a job offer from another company two weeks later. I have also worked for over eight companies as a contractor and had to go through the same hoops in each.

This piece is not a guide to get into big tech, but rather somewhere in the middle-high range where you can grow, have a balance, and still make good money. So here are my five learnings from my experience:

Be a good engineer.

The article's most essential and irreplaceable point is that you can't swindle your way around getting a software developer job. You need to read and put in the effort to practice coding challenges.
I recommend a few resources for this: roadmap.sh will familiarize you with the concepts you need to learn and provide valuable resources to understand them.

I also recommend neetcode.io to try your hand at practicing coding challenges and essential concepts.

Apply to everything fast.

This advice is controversial, but this is what works for me and a few other people I've talked with. Our current job market is a mess; Some companies post ghost jobs that they don't intend to fill, [1][2], others fill the position and forget their post, and others are almost done with their recruitment process, so the odds are against you, and others.

My solution is to apply to everything quickly, sort postings by date, and apply to every job related to what you want, even in companies you don't like.
Now, you either get an opportunity to interview for a company you like or you get practice interviewing with a company you don't like. Remember, you can always turn down an offer.

Note: I have heard that this is mean and that you are wasting people's time. This point is debatable, but the short answer is that most companies have their interview process automated, and most companies don't care if they are wasting your time with many rounds of interviews. You should follow your moral compass, but don't feel bad for doing what you must do.

I usually hear this kind of argument from underrepresented people in tech, especially women. If it helps, most companies want to attract more BIOPC, LGBTQ+, and woman coders, so apply liberally. [3] [4] [5]

Where to apply?

I don't like LinkedIn, but in Canada, there are excellent offers at Indeed.com, Levels.fyi and my favorite Hired.com, a friend also recommended simplify.jobs.

Tips for immigrants

In Canada, it is generally not legal for employers to ask about your immigration status during the hiring process [6]. But if you are requested your immigration status after receiving a job offer, you should disclose it at this point. [7].

But then again, if you want the job, you will disclose it if they ask. My advice is to be honest, always have your papers in order, and keep your answers short so you don't dig a hole for yourself. If you are worried about this, contact an immigration lawyer.

Be patient.

I sent almost 100 applications before getting an offer, and earlier in my career, there were times when I spent months and over 300 applications before getting a job. Be patient and learn what you are comfortable negotiating. Plenty of companies are out there, and work is a big part of the day, so feel free to let one offer slip out if you don't fit in the culture. But don't be too picky, you might realize that you enjoy working at a company after all.

Sources:

Fixing (and removing) commits in a git branch for beginners.

Cesar Vega — Sun, 01 Oct 2023 14:34:27 +0000

We have all been there. You want to merge and have a different set of commits that you want to have. Maybe you rebased a branch you shouldn't have or checked out from the wrong branch. But don't worry, fixing it is easy.

In this article, I will show a few techniques to get your branch exactly how you want it and avoid merging code and commits that do not belong in your target branch.

Let's start with an example where we have four commits:
git log --oneline

c761a8f (HEAD -> my-feature) commit-3
e056796 bad-commit-1
269a02d commit-2
ceaab87 commit-1

We can see that a bad commit snuck into our branch, so how do we fix it?
It's simple: First, we make sure the commit is unnecessary and want to remove it.
We can do this with:

git show e056796
or
git diff e056796^!

And then, we can see what our commit did.

Pro tip: This command will look prettier if you have customized your terminal with tools like ohMyZSH

Our second step is to take that commit out of our history. I do this by rebasing our branch. We would do an interactive rebase to our target branch in our example.

git rebase -i target-branch

An editor (often Vim or Nano) will open, showing the last commits. It'll look something like this:

pick ceaab87 commit-1
pick 269a02d commit-2
pick e056796 bad-commit-1
pick c761a8f commit-3

So, to keep the commits we want, delete the line corresponding to the bad commit (bad-commit-1):


pick ceaab87 commit-1
pick 269a02d commit-2
pick c761a8f commit-3

Exit and save the file.

Pro tip: For Vim, press "i" to interact with the text. And then, you click "ESC" -> "wq" to save and exit.

Finally, if you've already pushed your branch to a remote repository before this change, you'll need to force push your changes:

git push origin your-branch-name --force-with-lease

And now you have a clean branch without all those pesky commits. Always double-check with your team if those commits are unnecessary, and remember that this will only affect YOUR branch, so don't be too scared to go through the process.

Understanding Coupling in React: Best practices and Examples

Cesar Vega — Mon, 25 Sep 2023 19:34:38 +0000

Coupling refers to the degree of interdependence between different modules or classes in a system.

What is Coupling?

Coupling speaks to how closely connected different components or modules are within an application. High coupling means that changes in one module may necessitate changes in many other modules. This results in a codebase that becomes increasingly difficult to maintain and modify over time. As such, best practices usually recommend minimizing coupling.

Separate Components by Responsibility

A prevalent form of coupling occurs when a single file or component assumes multiple responsibilities (Look at the Single Responsibility Principle). We should avoid patterns where a component takes on multiple roles; For example, having a component determine if it should render as a header or footer based on props:

const HeaderOrFooter = ({ isHeader }) => {
    if(isHeader){
        return (<div className="header">...</div>)
    } 
    return (<div className="footer">...</div>)   
}

Instead, consider creating distinct components for different roles and handling display logic at the parent level:

const ParentComponent = () => {
    ...
    isHeader ? <Header /> : <Footer />
}

const Header = () => {
    return (<div className="header">...</div>) 
}
const Footer = () => {
    return (<div className="footer">...</div>)   
}

Avoid Prop Drilling

Prop drilling refers to the practice of passing props from a parent component down through its descendants. If your components are tightly intertwined with a shared state, it's a clear sign of tight coupling.

const ParentComponent = () => {
    ...
    const [prop1, setProp1] = useState()
    const [prop2, setProp2] = useState()
    const [prop3, setProp3] = useState()

    <ChildComponent prop1={prop1} .... prop3={prop3}/>
}

const ChildComponent = ({prop1, prop2, prop3}: IChildComponent) => {
    <GrandChildComponent prop1={prop1} .... prop3={prop3}/>
}

To combat this, you can use shared context or architect your components with a clearer separation of concerns. Remember to use context carefully to avoid bloating the global state.

const ParentComponent = () => {
    const [prop1, setProp1] = useState()
    const [prop2, setProp2] = useState()
    const [prop3, setProp3] = useState()
    ...
    <ChildComponent />
}

const ChildComponent = () => {
    ....
    <GrandChildComponent />
}

const GrandChildComponent = () => {
    const {prop1, prop2, prop3} = useContext('SharedContext');
    return (...)
}

Fetch Data Close to Where It's Used

This is more of a personal preference, but I like fetching and managing data as close to its usage point as possible. This helps reduce unnecessary props passed down and keeps data handling within the concerned component.

const ParentComponent = () => {
    ...
    const data = useGetData()
    <ChildComponent data={data}/>
}

A better approach:

const ParentComponent = () => {
    ...
    <ChildComponent />
}

const ChildComponent = () => {
    data = useGetData();
    ....
}

In conclusion, managing coupling is essential for scalable and maintainable applications. By separating concerns, avoiding prop drilling, and fetching data where it's used, we can significantly reduce the effects of high coupling and build more robust React applications.

useContext to manage state between React Sibling Components.

Cesar Vega — Tue, 12 Sep 2023 14:47:26 +0000

Have you ever wanted two separate components that share common state? Maybe a controller component and a display component where one component deals with the controls and the other with displaying it. Something like this:

const [a, setA] = useState()
...
...
...

(
<Box className="grid gap-4" style={{ gridTemplateColumns: "1fr 1fr" }}>
     <GameGrid a={a} b={b} c={c}/>
     <GameControls setA={setA} setB={setB} setC={setC}/>
</Box>
)

It might be okay if we just pass a couple props, but even with few props it feels wrong. So, how do we do it?

Share context between sibling components.

To do this you need to create a context object and wrap the components in it. And then you can get the context in each object, regardless of where you manage the sate.

const GameContext = createContext<IGameControls>({
  a: 'x'
  setA: () => void
  ....
});

export const Game = () =>{
 const contextValue: IGameControls = {
    a,
    setA,
    b,
    setB,
    ....
  };

return (
    <GameContext.Provider value={contextValue}>
      <Box className="grid gap-4" style={{ gridTemplateColumns: "1fr 1fr" }}>
        <GameGrid />
        <GameControls />
      </Box>
    </GameContext.Provider>
  );
}

One important thing to pay attention to is that we only share this state between the sibling components, so the rest of the code is not burdened by this data.

And now we can get the context in each component easily:

const { a, setA, .... } = useGameContext();

Extra sources:

Next.js server prop did not match client prop; And conditional style/class rendering

Cesar Vega — Mon, 11 Sep 2023 22:01:11 +0000

Have you ever gotten the enigmatic Next.js error: "Warning: Prop "{your-prop}" did not match. Server: "{value-1}" Client: "{value-2}"?

Here is the fun fact, conditional rendering did not cause this error. But at the beginning I thought it did, that's why I created this post, so everyone struggling to get rid of that error can understand why it happens, and how to solve it.

Here is our example:

type TGrid = (0 | 1)[][];

const generateRandomTiles = () => {
  const grid: TGrid = [];
  for (let i = 0; i < numRows; i++) {
    grid.push(Array.from(Array(numCols), () => (Math.random() > 0.7 ? 1 : 0))); // returns a live cell 70% of the time
  }
  return grid;
};

export const Game = () => {
  const [grid, setGrid] = useState<TGrid>(generateRandomTiles());

  return (
    grid?.map((rows, i) =>
      rows.map((col, k) => {
          return (
            <div
              // classNames is a library that combines class texts. But this can be thought as "w-4 h-4 border-solid border border-gray-400" + grid[i][k] ? "bg-pink-400" : "bg-white"
              className={classNames(
              "w-4 h-4 border-solid border border-gray-400",
              grid[i][k] ? "bg-pink-400" : "bg-white"
              )}
              key={`${i}-${k}`}
            />
          )
      })
    )
  );
};

This code causes the following error to fire:

Warning: Prop className did not match. Server: "w-4 h-4 border-solid border border-gray-400 bg-white" Client: "w-4 h-4 border-solid border border-gray-400 bg-pink-400"

So I thought it happened because I conditionally rendered bg-pink-400 and bg-white. But it wasn't, the real problem is a little more sneaky than that.

Do not generate values when defining useState.

The real culprit is this the line where we define our grid state:
const [grid, setGrid] = useState<TGrid>(generateRandomTiles());

The problem here is that Next.js has certain state in mind when we generate the tiles in the server, but when the client runs hydrates, we end up with a different random array when we generateRandomTiles() in the frontend. You can notice this if you console log grid, and check your next.js terminal log and your frontend log.

There is a great article by react.gg about this: https://ui.dev/c/react/effects?ck_subscriber_id=2248853627

How do we fix it?

Simple, we manage effects on the frontend. Like this:


const [grid, setGrid] = useState<TGrid>();

  useEffect(() => {
    const initialGrid = generateRandomTiles();
    // Comment, first refresh
    setGrid(initialGrid);
  }, []);

Now we will not have a mismatch between frontend and backend style rendering, and the error will not happen anymore.