Stop renting auth. Make it yours instead.(Sponsored)
Developer-Centric: True API first design, quick integration, built on standards, highly flexible & customizable.
Hosting Flexibility: You host or we host - the choice is yours with no loss of features.
Unlimited: Unlimited IDPs, unlimited users, unlimited tenants, unlimited applications, always free.
Total Control: Deploy on any computer, anywhere in the world and integrate easily with any tech stack.
Scale Confidently: Lightning-fast performance for 10 users or 10 million users (or more).
Data Isolation: Single tenant by design means your data is physically isolated from everyone else’s.
FusionAuth is a complete auth & user platform that has 15M+ downloads and is trusted by industry leaders.
This week’s system design refresher:
Top 6 Tools to Turn Code into Beautiful Diagrams
?ByteByteGo System Design Course Black Friday Promo ?
Pessimistic vs Optimistic Locking
Explaining JSON Web Token (JWT) with simple terms.
HTTP/1 -> HTTP/2 -> HTTP/3
SPONSOR US
Top 6 Tools to Turn Code into Beautiful Diagrams
Diagrams
Go Diagrams
Mermaid
PlantUML
ASCII diagrams
Markmap
Over to you: Did we miss anything? What's your favorite?
?ByteByteGo System Design Course Black Friday Promo ?
Yearly Black Friday sale is now up! Use code BF2024 at checkout for 30% off the system design interview online course.
To take advantage of the limited-time offers, subscribe before 11:59 pm PST on Monday, December 2nd.
Use code: BF2024
Pessimistic vs Optimistic Locking
Locks are essential to maintain data consistency and integrity in multi-user environments. They prevent simultaneous modifications that can lead to data inconsistencies.
Pessimistic locking assumes conflicts will occur and locks the data before any changes are made. It prevents other users from accessing and updating the data until the lock is released.
Optimistic locking assumes conflicts are rare. It allows multiple users to access data simultaneously and checks for conflicts when changes are committed. If a conflict is detected, the operation is rolled back.
Some best practices to consider:
Hold locks for the minimum possible time to reduce contention.
Apply locks at the most granular level such as rows rather than tables.
Implement retry logic for transactions that fail due to conflicts.
Pessimistic locking is better for data integrity but can impact performance.
Optimistic locking is better for efficiency and performance.
Over to you: Which locking mechanism have you used?
Explaining JSON Web Token (JWT) with simple terms
Imagine you have a special box called a JWT. Inside this box, there are three parts: a header, a payload, and a signature.
The header is like the label on the outside of the box. It tells us what type of box it is and how it's secured. It's usually written in a format called JSON, which is just a way to organize information using curly braces { } and colons : .
The payload is like the actual message or information you want to send. It could be your name, age, or any other data you want to share. It's also written in JSON format, so it's easy to understand and work with.
Now, the signature is what makes the JWT secure. It's like a special seal that only the sender knows how to create. The signature is created using a secret code, kind of like a password. This signature ensures that nobody can tamper with the contents of the JWT without the sender knowing about it.
When you want to send the JWT to a server, you put the header, payload, and signature inside the box. Then you send it over to the server. The server can easily read the header and payload to understand who you are and what you want to do.
Over to you: When should we use JWT for authentication? What are some other authentication methods?
HTTP/1 -> HTTP/2 -> HTTP/3
HTTP 1 started in 1996 followed by HTTP 1.1 the very next year. In 2015, HTTP 2 came about and in 2019 we got HTTP 3.
With each iteration, the protocol has evolved in new and interesting ways.
HTTP 1 (and its sub-versions) introduced features like persistent connections, pipelining, and the concept of headers. The protocol was built on top of TCP and provided a reliable way of communication over the World Wide Web. It is still used despite being over 25 years old.
HTTP 2 brought new features such as multiplexing, stream prioritization, server push, and HPACK compression. However, it still used TCP as the underlying protocol.
HTTP 3 uses Google’s QUIC, which is built on top of UDP. In other words, HTTP 3 has moved away from TCP.
Over to you: What would you add to understand the evolution of HTTP over the years?
SPONSOR US
Get your product in front of more than 1,000,000 tech professionals.
Our newsletter puts your products and services directly in front of an audience that matters - hundreds of thousands of engineering leaders and senior engineers - who have influence over significant tech decisions and big purchases.
Space Fills Up Fast - Reserve Today
Ad spots typically sell out about 4 weeks in advance. To ensure your ad reaches this influential audience, reserve your space now by emailing sponsorship@bytebytego.com.
