Introduction
This has been one of the toughest weeks I've experienced since starting this challenge.
There were moments when I doubted myself, questioned my progress, and wondered whether all the effort and consistency would eventually pay off.
While I was trying to keep learning, improving my skills, and looking for new opportunities, my phone also got damaged, making things even more difficult. For a while, I couldn't properly connect to the internet or keep up with everything I needed to do.
I found myself asking:
Will I ever get an opportunity? Will all this effort and consistency eventually pay off?
Despite those thoughts, I kept going.
On the learning side, I continued going deeper into software architecture and backend system design. This week, I completed Concurrency Design Patterns and started exploring Microservices Architecture and related concepts such as SOA, Twelve-Factor Apps, Cloud-Native Applications, Serverless Computing, DevOps, and Reactive Microservices.
These topics challenged me technically, but the challenges outside of learning also reminded me why consistency matters.
I'm learning that #100DaysOfCode isn't just about writing code every day. It's also about showing up when things don't go according to plan, continuing when progress feels slow, and trusting the process even when the outcome isn't clear.
I'm leaving the rest in God's hands and praying that everything works out for the best.
For now, I'll keep learning, keep applying, keep improving, and keep showing up. 💙
"Success is the sum of small efforts, repeated day in and day out."
— Robert Collier
Day 59: Completing Concurrency Patterns
On day 59, I completed the remaining parts of the Implementing Concurrency Patterns chapter.
What I Learned
- The Half-Sync/Half-Async Pattern
- The Leader/Follower Pattern
- The Reactor Pattern
- Thread-Specific Storage
- Using
ExecutorServiceand thread pools - Best practices for building concurrent applications
One thing that became clearer to me was how concurrency patterns help structure applications that need to handle multiple tasks or requests at the same time.
I also learned that concurrency isn't just about creating multiple threads. Different patterns exist to manage how tasks are scheduled, synchronized, and executed while keeping applications efficient and reliable.
Another chapter completed, and another step toward understanding how multithreaded applications are designed and managed.
Day 60: Starting Microservices
On Day 60, I started Chapter 9: Demystifying Microservices.
What I Learned
- What Microservices are
- The business demands that contributed to their evolution
- How technology influenced the evolution of Microservices
- The evolution of imperative architecture
- How Microservices organize applications around autonomous, self-contained, and loosely coupled business capabilities
This was the beginning of my journey into Microservices, and it helped me start understanding why this architectural style evolved and the problems it aims to solve in modern software systems.
There was still a lot more to explore, but this gave me a foundation for the sections that followed.
Day 61: Understanding Microservices Architecture
On Day 61, I continued learning about Microservices Architecture and went deeper into what makes a microservice different from simply splitting an application into smaller services.
What I Learned
- The honeycomb analogy for understanding Microservices
- Single responsibility and service autonomy
- Key characteristics of Microservices
- Lightweight and polyglot architecture
- The importance of automation and supporting ecosystems
- How services can be distributed and dynamic
- Antifragility, fail-fast, and self-healing systems
This section helped me understand that Microservices is not simply about having many small services. The services need to be autonomous, loosely coupled, resilient, and capable of evolving independently.
It also made me realize that designing distributed systems involves many considerations beyond writing the actual business logic.
Day 62: Understanding the Benefits of Microservices
On Day 62, I continued learning about Microservices and focused on the benefits of adopting a microservices architecture.
What I Learned
- Supporting polyglot architecture
- Enabling experimentation and innovation
- Selective and elastic scalability
- Allowing substitution of services
- Helping manage technology debt
- Supporting different versions of services
- Supporting self-organizing systems
- Enabling event-driven architecture
- Enabling DevOps practices
I also learned about the Scale Cube, which describes three approaches to scaling:
- X-axis: Horizontally cloning the application
- Y-axis: Splitting different functionality
- Z-axis: Partitioning or sharding data
Microservices isn't just about breaking an application into smaller services. There are specific architectural benefits and trade-offs behind the approach, especially when it comes to scalability, flexibility, and independent evolution.
I'm continuing to build my understanding of not just what Microservices are, but why organizations choose this architecture.
Day 63: Exploring Related Architecture Styles
On Day 63, I started a new chapter: Related Architecture Styles and Use Cases.
What I Learned
I was introduced to several architecture styles and concepts, including:
- Service-Oriented Architecture (SOA)
- Twelve-Factor Apps
- Serverless Computing
- Lambda Architectures
- DevOps
- Cloud & Containers
- Reactive Microservices
I also started learning about Service-Oriented Architecture (SOA) and how it approaches software development through services and business capabilities.
It's still early in the chapter, but I'm looking forward to understanding how these different architectural approaches relate to modern software systems.
Day 64: Exploring Related Architecture Styles and Use Cases
On day 64, I continued learning about Related Architecture Styles and Use Cases, exploring how different architectural approaches support modern software systems.
What I Learned
- Service-oriented integration
- Legacy modernization
- Service-oriented applications
- Monolithic migration using SOA
- The Twelve-Factor App methodology
- Cloud-native applications
- Serverless computing
I also explored several Twelve-Factor App principles, including:
- Single codebase
- Bundled dependencies
- Externalized configuration
- Addressable backing services
- Separation of build, release, and run
- Stateless processes
- Port binding
- Concurrency for scaling
- Disposability
- Development/production parity
- Externalized logs
- Admin processes
I'm beginning to understand how these principles help make applications more scalable, maintainable, and suitable for modern cloud environments.
Goals for Week 11
As I move into Week 11, I want to become more intentional about turning the concepts I've been learning into practical skills.
Here are my goals for Week 11:
- Practice LeetCode consistently and improve my problem-solving skills
- Continue doing mock technical interviews and work on explaining my thought process
- Keep applying for backend engineering opportunities
- Continue learning and practicing Spring Security
- Build practical examples using the Spring concepts I've studied
- Review Java, Data Structures, and Algorithms for technical interviews
- Continue learning Python for scripting and fast prototyping
- Improve and revisit some of my existing projects
- Stay consistent with #100DaysOfCode and continue documenting my journey
This past week, I continued going deeper into software architecture and backend system design.
I completed Concurrency Design Patterns and started exploring Microservices Architecture, learning about its evolution, characteristics, benefits, scalability, and the principles behind building autonomous and loosely coupled services.
I also began exploring related architecture styles and concepts, including Service-Oriented Architecture (SOA), Twelve-Factor Apps, Cloud-Native Applications, Serverless Computing, DevOps, and Reactive Microservices.
A lot of these topics challenged me to think beyond simply writing code and start understanding how larger systems are structured, scaled, modernized, and designed to evolve independently.
Going forward, I want to spend more time building practical projects, applying the architectural concepts I'm learning, and testing my understanding instead of only consuming information. I also want to continue improving my problem-solving skills, preparing for technical interviews, and actively looking for backend engineering opportunities.
I'm still working toward becoming a stronger backend engineer, and there's still a lot to learn. But I'm taking it one step at a time and continuing to show up. 💙
Let's keep building. 💙
LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/
X (Twitter):
https://x.com/spider337761
Top comments (0)