RaulJunco

devs

4 ways to scale.

A simple monolithic application can do very well for years.

But, if the business becomes successful, which means more customers and more load, you might need to change your system to support the next level of growth.

Here are the things that can help:

Vertical scaling
In a nutshell, this means getting a bigger machine.

Horizontal Duplication
Having multiple things capable of doing the same work.

Data Partitioning
Dividing work based on some attribute of the data, e.g., customer group.

Functional Decomposition
Separation of work based on the type: I’m talking about microservices.

Some forms of scaling—Vertical scaling and Horizontal duplication—can have a limited impact on your system's architecture.

If you need more, a redesign may involve:

• splitting apart an existing monolith
• choosing new data stores to handle the load better
• moving from synchronous request-response to event-based systems.

Here is some advice: do the easy stuff first. 

Vertical scaling and horizontal duplication are quick and easy compared with the other two.

If you need to change our systems to deal with scale, it isn't a sign of failure.

It is a sign of Success.

![](https://m.stacker.news/33601)

The Architecture that gets you here won't take you there.

One of the most underrated skills for Software Engineers. 😅

Exceptions can jump the execution flow across methods, classes, or even layers.

They make the code harder to follow and understand.

Your system can throw exceptions for multiple reasons:

- A consumer sends bad arguments.

- An IO operation may fail.

- In distributed systems, a network can fail or produce a delay. 

- You encounter an unexpected null value.

This is how you make it less complex:

- Use exceptions for exceptional conditions, not regular control flow.

- If you have to throw it, write clear error messages and include context.

- Prefer specific exceptions over general ones.

- Use ‘finally’ blocks or language-specific constructs to ensure resources are released.

- Keep your handling logic simple and avoid deep nesting.

- Test your code for exception handling.

It is already hard to write code, but it is even harder to deal with special conditions. 

![](https://m.stacker.news/33094)

Exception handling is the worst source of complexity.

Design

It's 90% about understanding the problem at hand.

Here's how to scale smart:

If you know you have a high read ratio vs. a low write ratio.

• Separate those services so they can scale differently.

For instance, in an e-commerce application, you might have a service for handling search queries (reads) and a separate service for updating product details (writes).

• Improve performance at the storage level.

You can set up 1 write DB, and 3 read replicas in a master-slave replication setup.

The master handles all write operations, and the replicas handle read operations.

• Add a cache layer.

You can cache product details or repeated queries. 

This will reduce the load on the database by serving frequently accessed data from memory.

Getting better business knowledge is the only way to have the right design.

![](https://m.stacker.news/32846)

System design isn't a cut-and-paste job. 

bitdevs

Choosing the right communication style can save you 50% of them.

You can classify the communication into major groups.

Synchronous & Blocking:

- REST over HTTP
- GRPC

With request-response (synchronous), we expect the response to return to the instance that sent the request.

Asynchronous & Nonblocking:

- Queue-Based brokers
- Even-Driven
- Common Data

With asynchronous communication, the response can come back later, even to a different instance.

One of my favorites is Even-Driven

Event-driven communication is, by definition, asynchronous.

A microservice emits an event, and other microservices can react if they are interested. 

An event is a statement that something happened (for example, OrderPlaced).

With event-driven communication, a microservice doesn't tell another microservice what to do. 

It's up to downstream microservices to make a judgment call on what they do with that information. 

Two things to consider:

1. Event-driven collaboration can promote more loosely coupled architectures. But, understanding how the system behaves requires more work. 

2. You also need a message broker, which can further complicate matters. 

Request-response and event-driven both have their place. 

Some problems just fit one model more than another, and it's common for a microservice architecture to have a mix of styles.

![](https://m.stacker.news/32747)

Many of the problems with microservices appear only once you hit production.

Photography

Recharging

Sagas provides a structured way to deal with them.

Distributed transactions add significant complexity to systems.

They have problematic failure modes; they may not always deliver the expected results even when they work.

There are two styles of sagas to consider: orchestrated and choreographed.

Orchestrated Sagas

A central orchestrator coordinates the sequence of events by calling the microservices involved in the saga.

Pros
- Simplicity and clarity in the process flow.

Cons

-The orchestrator becomes a single point of failure.
-The orchestrator becomes a bottleneck when many teams work on the same business process.

Choreographed Sagas

With choreographed sagas, there is no central coordinator. Microservices react to events published by other services to continue the process.

Pros

- Reduced coupling
-Better scalability across teams.

Cons

- Increased complexity in guaranteeing the correct sequence of events and handling compensations.
-I have worked more with choreographed sagas. 

Orchestrated sagas work fine when a single team handles the whole process. But, they become more problematic with many teams. 

Choreographed sagas work better when many teams need to work together.


![](https://m.stacker.news/32294)


Distributed Transactions are the root of all evil.

7 concepts you need to master cache.

Cache Hit Ratios

This is the answer to how effective your cache strategy is.
A high hit ratio indicates that the cache frequently contains the requested 
data.

A high hit ratio minimizes fetching it from slower layers.

Eviction Policies

They determine which data stays in the cache and which gets removed; it's about efficiency. 

Common policies include:
- Least Recently Used (LRU)
- Most Recently Used (MRU)
- Least Frequently Used (LFU)

Cache Coherence

Of course, it gets more complex In distributed systems.

Maintaining data consistency across these caches is critical. 

Cache coherence ensures that all copies of a data item reflect the most recent version.

Cache Granularity

This is about the size of the data units stored in the cache.

Granularity decisions impact the cache's efficiency and hit ratio.

How much data do you need to store in each operation?

Cache Warm-up

Preloading the cache with data expected to be in high demand will improve performance.

Especially in systems where cache hits are critical for speed.

Cache Partitioning

In a well-organized toolbox, you'd have separate compartments or trays for different tools.

Cache partitioning is the same. It's about dividing the cache into different sections, each tailored for a specific data type or request. 

This organization improves the cache since retrieving the data is easier and faster. 

Cache Compression

When space is at a premium, compressing cached data allows you to store more information. 

But, this comes with the trade-off of processing overhead during compression and decompression.

Caching isn't just dumping data somewhere and forgetting about it.

It's also about what, how, and when you store data to make your system faster.

![](https://m.stacker.news/31908)

I thought Cache was only about storing my data for quick access, and I was wrong

This book is pure gold, you learn a lot

1. Write a list of the main entities and concepts in the domain.

This includes objects, processes, and roles.

Write a short paragraph explaining each main entity or concept's purpose and role in the system.

2. Use Sequence Diagrams for workflows.

Sequence Diagrams will illustrate how objects interact with each other in a particular scenario.

They help understand the flow of operations and the roles of different components in the system.

3. Create Class Diagrams.

I use class diagrams to show the structure of these entities:

- attributes
- methods
- relationships 

4. Add links to the Code for Details.

Include references or links to the relevant sections of the codebase for those who want to explore implementation specifics in depth.

This is just an entry point; you can redirect people to your code, where the implementation details are.

5. Invest in your Tests

Catching bugs early in the development cycle is a sweet treat.

Nothing replaces the confidence of running a good test suit.

I do all these things not because someone tells me to do it but because:

- Save me time on every decision
- keep the team on the same page
- help onboarding new people (not just developers)

![](https://m.stacker.news/31504)

5 things that help you build better software.

BooksAndArticles

1. Head First Design Patterns
2. Fundamentals of Software Architecture
3. Software Architecture: The Hard Parts 

If you like System Design, buy at least one of these.

![](https://m.stacker.news/31398)

3 books to learn System Design:

 But what does that mean?

Inheritance establishes an "Is-a" relationship between a base class and a subclass.

It's a quick and intuitive way to share attributes and behavior between classes. 

The problem is that it is difficult to maintain because:

1. Subclasses depend on parent class implementation. It is hard to navigate.

2. Subclasses inherit all parent class behaviors, even if they don't need them.

3. Overriding parent class behavior can introduce bugs.

Composition, on the other hand, forms a "Has-a" relationship.

The idea is to build more complex objects by combining simpler objects. Because:

1. Components are reusable across different classes.

2. It's easy to change behavior at runtime by changing the components of a class.

3. Smaller, self-contained components are easier to change.

4. Components are independent and interact through well-defined interfaces, reducing their dependencies.

Pros of Composition:
 
- Easy to Test individual components.
- Components are easier to change.
- You can swap components at runtime.
- Promotes Encapsulation and Single Responsibility Principle.

Cons of Composition:

- Increase the number of objects in a system.

Favoring composition doesn't mean inheritance is an obsolete concept.

Inheritance is still useful, especially when objects need to behave in a similar way.

![](https://m.stacker.news/30961)

Senior Developers understand Composition Over Inheritance.

the world could be on fire and we wouldn’t know

Collisions occur when two different keys produce the same hash code, leading to a collision in the hashmap.

Handling collisions is a critical aspect of hashmap implementation.

Resolution techniques:
- Chaining
- Open Addressing

![](https://m.stacker.news/30805)

Collisions

6 ways to test in Prod.

A/B testing

With an A/B test, you deploy two versions of the same functionality; some users see either the "A" or the "B" version.

You are then able to see which version of the functionality performs best.

Use this when deciding between two different approaches for how something.

For example, you might try two different customer registration forms to see which is more effective in driving sign-ups.

Canary release

You allow some of your users to see the new functionality release.

If this new functionality works well, you can increase the number of users who see it until all users can see the new version.

If the new functionality doesn't work as intended, you will only affect a few of your users.

You can either revert the change or try fixing any problem.

Parallel run

You execute two similar implementations of the same functionality with a parallel run.

Any request is routed to both versions so you can compare their results, although the user sees only one.

This is very useful when we want to understand better the change, such as how it is performing.

Smoke Tests

You run these after deploying your new version in Prod, but before releasing it.

These tests are often automated and can go from very simple activities (is a service running?) to executing complex operations.

It acts as a quick validation step to catch major issues early.

Synthetic transactions

Fake user interaction with the system.

It's often very close to the end-to-end test you might write.

Placing an Order is a great example.

Chaos engineering

Chaos engineering is the injection of faults into a production system to ensure it can handle it.

The best-known example of this technique is probably Netflix's Chaos Monkey.

Chaos Monkey can turn off virtual machines in Production. The idea is that the system is robust enough that these shutdowns don't interrupt the end user.

A couple of things to consider:

• Set some fake users in Production.

• If you order products, make sure they are fake (you don't want 200 sofas arriving at your head office).

![](https://m.stacker.news/30741)

Testing in Production is also a way of monitoring.

Stubs are controllable implementations of dependencies that return predefined responses.

Isolate your code from external dependencies:
- Databases
- APIs
- External services.

So you can focus on testing the behavior of your code.

![](https://m.stacker.news/30622)

Set up Stubs

- Keep track of what's going on

- Test each part individually

- Make changes without unexpected side effects

This is the meaning of the Single Responsibility Principle.

This is a great question, Haider; here are 4 tips I use to improve SRP:

- Find a good name; often, searching for a good name reveals you have too many responsibilities in your class or method.

- Writing your tests also helps; if you find yourself asserting multiple things in your tests, that can be a signal.

- Code Reviews with more seniors help a lot

- Refactor every time you have the opportunity to improve.

![](https://m.stacker.news/30598)

When each piece of your code has one clear purpose, it's easier to:

• Understand the problem first, then code.

• Tests make better software.

• Document for your future self.

• Sometimes, letting the application crash is better than doing nothing.

• You need to monitor your systems.

• The secured user data is the one you don't capture.

• Keep a list of "Things I Don't Know but want to learn."

7 Things I learned the hard way:

Will your robot re-program itself to follow instructions like "can you move the red boxes over there?"

Translating natural language instructions to code is a challenging problem.

But...
👇

![](https://m.stacker.news/30395)

This could be an alternative approach to using machine learning for more simple tasks.

So, the robot can reprogram itself, creating the code instructions for the hardware to execute the action you are asking for..

Do I need to start looking for a new role? 😱

Five lessons I learned from a lazy developer.

Why spend hours on manual work when you can write a script that completes the same task in seconds?

Lazy developers value efficiency. 

They find clever ways to automate repetitive tasks, saving time and effort.

Lazy developers embrace the DRY principle: Don't Repeat Yourself.

They understand the importance of code reuse and modular design. 

The goal is to build a solid foundation that can be easily maintained and expanded upon so they can make their lives easy.

Lazy developers prioritize testing.

They hate doing repetitive manual testing or relying on human intervention for every task.

Instead, they invest time in writing automated tests and continuous integration systems.

Lazy developers don't like to be "On Call".

They want to enjoy time with family or gaming; some even touch grass.

Instead, they watch their system, and when they discover something bad, they fixed during the work day so they don't have to worry later.

Lazy developers seek to improve.

They hate reinventing the wheel and looking for existing solutions before starting from scratch. 

To accelerate development, they leverage on:

- Libraries
- Frameworks
- Open-source projects

Being lazy as a developer isn't about being idle; It's about working smarter, not harder.

What kind of developer are you (or want to be)? 😉

![](https://m.stacker.news/30327)