EP93: Is Passkey Shaping a Passwordless Future?
This week’s system design refresher:
Top 9 Most Popular Types of API Testing (Youtube video)
Is Passkey Shaping a Passwordless Future?
How can Cache Systems go wrong?
Big Endian vs Little Endian
How do we incorporate Event Sourcing into the systems?
Implement passkey authentication in minutes (Sponsored)
Join TikTok, Uber, Amazon, and other leading tech companies by giving your users a faster and more secure sign-in experience with passkeys. Building an in-house auth solution takes months and is a challenge to roll out to users. But there’s a better way. Passage by 1Password is a cross-platform, ready-to-ship auth solution for passkeys. ByteByteGo readers get an exclusive six-month free trial – just use the code ‘BYTEBYTEGO6MO’ once you sign up in the console.
Top 9 Most Popular Types of API Testing
Is Passkey Shaping a Passwordless Future?
Google announced PassKey support for both Android and Chrome recently.
Passkeys, also backed by Apple and Microsoft, is claimed to be a significantly safer replacement for passwords.
The diagram below shows how PassKeys work.
Step 1 - create PassKeys
The end-user needs to confirm the account information and present their credentials (face ID, touch ID, etc.).
A private key is generated based on the public key provided by the website. The private key is stored on the device.
Step 2 - sign in with PassKeys on devices
When the user tries to sign in to a website, they use the generated private key. Just select the account information and present the credentials to unlock the private key.
Consequently, there is no risk of password leakage since no passwords are stored in the websites' databases.
Passkeys are built on industry standards, and it works across different platforms and browsers - including Windows, macOS and iOS, and ChromeOS, with a uniform user experience.
How can Cache Systems go wrong?
The diagram below shows 4 typical cases where caches can go wrong and their solutions.
Thunder herd problem
This happens when a large number of keys in the cache expire at the same time. Then the query requests directly hit the database, which overloads the database.
There are two ways to mitigate this issue: one is to avoid setting the same expiry time for the keys, adding a random number in the configuration; the other is to allow only the core business data to hit the database and prevent non-core data to access the database until the cache is back up.Cache penetration
This happens when the key doesn’t exist in the cache or the database. The application cannot retrieve relevant data from the database to update the cache. This problem creates a lot of pressure on both the cache and the database.
To solve this, there are two suggestions. One is to cache a null value for non-existent keys, avoiding hitting the database. The other is to use a bloom filter to check the key existence first, and if the key doesn’t exist, we can avoid hitting the database.Cache breakdown
This is similar to the thunder herd problem. It happens when a hot key expires. A large number of requests hit the database.
Since the hot keys take up 80% of the queries, we do not set an expiration time for them.Cache crash
This happens when the cache is down and all the requests go to the database.
There are two ways to solve this problem. One is to set up a circuit breaker, and when the cache is down, the application services cannot visit the cache or the database. The other is to set up a cluster for the cache to improve cache availability.
Over to you: Have you met any of these issues in production?
Latest articles
If you’re not a paid subscriber, here’s what you missed this month.
To receive all the full articles and support ByteByteGo, consider subscribing:
Big Endian vs Little Endian
Microprocessor architectures commonly use two different methods to store the individual bytes in memory. This difference is referred to as “byte ordering” or “endian nature”.
Little Endian
Intel x86 processors store a two-byte integer with the least significant byte first, followed by the most significant byte. This is called little-endian byte ordering.Big Endian
In big endian byte order, the most significant byte is stored at the lowest memory address, and the least significant byte is stored at the highest memory address. Older PowerPC and Motorola 68k architectures, often use big endian. In network communications and file storage, we also use big endian.
The byte ordering becomes significant when data is transferred between systems or processed by systems with different endianness. It's important to handle byte order correctly to interpret data consistently across diverse systems.
How do we incorporate Event Sourcing into the systems?
Event sourcing changes the programming paradigm from persisting states to persisting events. The event store is the source of truth. Let's look at three examples.
New York Times
The newspaper website stores every article, image, and byline since 1851 in an event store. The raw data is then denormalized into different views and fed into different ElasticSearch nodes for website searches.CDC (Change Data Capture)
A CDC connector pulls data from the tables and transforms it into events. These events are pushed to Kafka and other sinks consume events from Kafka.Microservice Connector
We can also use event event-sourcing paradigm for transmitting events among microservices. For example, the shopping cart service generates various events for adding or removing items from the cart. Kafka broker acts as the event store, and other services including the fraud service, billing service, and email service consume events from the event store. Since events are the source of truth, each service can determine the domain model on its own.
Over to you: Have you used event sourcing in production?
In Passkey description: "A private key is generated based on the public key provided by the website. The private key is stored on the device."
Should not these key be generated in the opposite order? How is it possible to generate private key based on public key?
In 3. Cache breakdown. "Never expiring" technique works only if the cached element never changes.
If an element may be changed over time, we could retrieve it in advance just before the cache expires, and just replace the value in cache with this value read in background. It would prevent massive querying expired value.
If I were a theorist in System Design, I would introduce such concept in my work dubbing it "Background cached value pre-retrieving" pattern.
By the way, this technique can be used not only for hit values, but for any value. Just need to configure "Background pre-retrieving interval". In this case, it would just eliminate waiting even for one or two occasional readers for database query roundup.