This week’s system design refresher:
Why Does Git Revert Cause Conflicts?
12 Claude Code Features Every Engineer Should Know
Symmetric vs. Asymmetric Encryption
7 Key Load Balancer Use Cases
How can Cache Systems go wrong?
Launching ByteByteGo Live
Why Does Git Revert Cause Conflicts?
git revert looks straightforward until it throws a conflict. Here’s why that happens.
What git revert actually does: Unlike reset, a revert doesn’t rewrite history. Instead, it creates a new commit that undoes the changes from an earlier one. This keeps your history clean, traceable, and safe for shared branches.
Why revert conflicts happen: Conflicts appear when a later commit changed the same lines as the commit you’re trying to undo.
Example in the diagram:
Commit C2 added a feature
Commit C3 changed those same lines
Reverting C2 now collides with changes from C3
Git can’t know which version is correct, so a revert conflict is triggered.
How to resolve it:
1. Run git revert C2
2. Git pauses when it hits the conflict
3. You manually fix the file
4. Stage it
5. Continue the revert
Git then creates a new commit that cleanly undoes C2 while keeping C3 intact.
Over to you: Have you ever hit a revert conflict at the worst possible moment? How did you resolve it?
12 Claude Code Features Every Engineer Should Know
CLAUDE. md: A project memory file to define custom rules and conventions. Claude reads at the start of every session.
Permissions: Control which tools Claude can and can’t use.
Plan Mode: Claude plans before it acts. You can review them before any code changes.
Checkpoints: Automatic snapshots of your project to revert to if something goes wrong.
Skills: Reusable instruction files Claude follows automatically.
Hooks: Run custom shell scripts on lifecycle events like PreToolUse or PostToolUse.
MCP: Connect Claude to any external tools like databases and third-party services.
Plugins: Extend Claude with third-party integrations containing skills, MCPs, and hooks.
Context: Feed Claude what it needs and manage the current context window with /context.
Slash Commands: Create shortcuts for tasks you run often. Type / and pick from your saved commands.
Compaction: Compress long conversations to save tokens.
Subagents: Spawn parallel agents for complex tasks. Divide large multi-step workflows and run them simultaneously.
Over to you: Which Claude Code feature do you use the most? Any features you wish were on this list?
Symmetric vs. Asymmetric Encryption
Symmetric and asymmetric encryption often get explained together, but they solve very different problems.
Symmetric encryption uses a single shared key. The same key encrypts and decrypts the data. It’s fast, efficient, and ideal for large amounts of data. That’s why it’s used for things like encrypting files, database records, and message payloads.
The catch is key distribution, both parties must already have the secret, and sharing it securely is hard.Asymmetric encryption uses a key pair. A public key that can be shared with anyone, and a private key that stays secret. Data encrypted with the public key can only be decrypted with the private key.
This removes the need for secure key sharing upfront, but it comes at a cost. It’s slower and computationally expensive, which makes it impractical for encrypting large payloads.
That’s why asymmetric encryption is usually used for identity, authentication, and key exchange, not bulk data.
Over to you: What’s the most common misunderstanding you’ve seen about encryption in system design?
7 Key Load Balancer Use Cases
Traffic Distribution: Load Balancers help evenly distribute traffic among multiple server instances.
SSL Termination: Load Balancers can offload the responsibility of SSL termination from the backend servers, thereby reducing their workload.
Session Persistence: Load Balancers ensure that all requests from a user hit the same instance to maintain session persistence.
High Availability: Improves the system’s availability by rerouting traffic away from failed or unhealthy servers to healthy ones.
Scalability: Load Balancers facilitate horizontal scaling when additional instances are added to the server pool to handle increased traffic.
DDoS Mitigation: Load Balancers can help mitigate the impact of DDoS attacks by rate limiting requests or distributing them across a wider surface.
Health Monitoring: Load Balancers also monitor the health and performance of server instances and remove failed or unhealthy servers from the pool.
Over to you: Which other load balancer use case will you add to the list?
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?
Launching ByteByteGo Live
Most online courses never get finished (~4% completion). Live cohorts get ~40%, roughly 10x higher. Live courses are the only courses people actually finish.
So we’re launching ByteByteGo Live. The lineup:
Build with Claude Code (John Kim, Senior Staff Engineer @ Meta, starting in a few days)
Build Production Grade AI Systems (Tanya Roosta, Director @ AMD, PhD UC Berkeley)
AI Engineering Fundamentals (Ali Aminian, Google, bestselling author)
AI Evals in Practice (Manjeet Singh, Senior Director @ Salesforce)
AI Cost Optimization (Jeremy Hintz, Engineering Lead @ Meta)
Rebuild YouTube with AI (Mikhail Sychev, Staff Software Engineer @ Google)
Trust-optimized AI Development (Kent Beck, Creator of TDD)
One membership includes every live course we run over the next 12 months, including new ones added along the way.