On October 19–20, 2025, AWS experienced a significant outage in the US-EAST-1 region lasting over 14 hours. The root cause was a “latent race condition” in DynamoDB’s DNS management system.

What is a race condition? It occurs when multiple threads try to access/update the same resource simultaneously, and the outcome depends on precise timing.

What is “latent race”? “Latent” means this bug existed in the system without being triggered — potentially for years. It’s like a landmine buried in your codebase, invisible until someone steps on it. Standard testing doesn’t catch it because the timing has to be “just wrong.”

How the race-condition happened in AWS Outage case ?

Please refer to the diagram to understand the root cause quickly. Understanding the role of “DNS Planner” and “DNS Enactor” is crucial:

• DNS Planner — Creates “plans” (lists of IP addresses for DynamoDB endpoints)
• DNS Enactor — Picks up plans generated by the DNS Planner and applies them to Route53 (3 independent instances in 3 Availability Zones). This component also includes a cleanup process to delete obsolete plans.

The Race Condition Timeline

~11:30 PM:

• Enactor #1 picks up Plan #100
• Does version check: “Is Plan #100 newer than current?” → YES ✓
• Starts updating Route53, but gets stuck retrying due to transaction conflicts

11:30 PM — 11:47 PM:

• Enactor #1 is still stuck retrying (18+ minutes of delays)
• During this time, DNS Planner keeps creating new plans: #101, #102… #150
• This is normal operation

11:47 PM:

• Enactor #2 picks up Plan #150 (the latest)
• Quickly applies it to ALL endpoints successfully
• Route53 now has Plan #150 → Everything working perfectly ✓
• Enactor #2 invokes cleanup: “Delete plans older than #140”

11:48 PM — THE RACE CONDITION TRIGGERS:

Two things happen at the exact same millisecond:

• Thread A (Cleanup): Deletes Plan #100 from storage
• Thread B (Delayed Enactor #1): Applies Plan #100 to Route53 regional endpoint, overwriting Plan #150

Result:

• Route53 regional endpoint now references Plan #100
• But Plan #100’s data was just deleted from storage
• DNS query returns: EMPTY (no IP addresses)
• DynamoDB becomes completely unreachable via DNS

Why Couldn’t It Self-Heal?

The automation tried to fix itself but couldn’t:

1. System asks: “What plan is currently active?”
2. Answer: “Plan #100” (according to Route53)
3. System looks for Plan #100 → NOT FOUND (it was deleted)
4. Deadlock: Can’t apply new plans without knowing current state; can’t determine current state because it references deleted data

The critical flaw: The version check happened at 11:30 PM at the START of Enactor #1’s process. By the time it actually applied the plan at 11:48 PM (18 minutes later), this check was stale. The system had no mechanism to re-validate the check before the final update.

Impact on Overall Outage and Different Services

As DynamoDB is a foundational service used internally by many AWS services, this immediately became a major issue.

Example: EC2 uses DynamoDB to store instance metadata. When DynamoDB became unreachable due to DNS issues, new EC2 instance creation immediately failed. This triggered multiple retry attempts and health alarms.

Even after fixing the DNS issue at 2:40 AM, the overall system took over 14 hours to fully recover due to cascading effects:

• Failed instance launches created massive retry queues
• When the system came back online, it was overwhelmed by the backlog
• Network Load Balancers experienced health check failures
• Lambda functions couldn’t process event sources

Services Impacted: EC2, Network Load Balancer, Lambda, ECS, EKS, Fargate, IAM, Redshift, Amazon Connect, and many others.

Regional Impact: This was a regional issue in N. Virginia (us-east-1), one of AWS’s largest and oldest regions, serving as a core hub for major global services.

Key Learnings on System Design for Developers and Architects

1. Race Conditions Are Inevitable in Distributed Systems — Design for Them

Finding “latent races” in large-scale systems is absolutely difficult. Instead of trying to prevent all race conditions, design systems that can detect and recover from them. It is hard job I know but this is new term we must be aware about hence forth.

2. Validation Must Happen at the Point of Action

Don’t validate once at the beginning of a multi-hour process. Re-validate immediately before critical operations. In this case, the version check at 11:30 PM was meaningless by 11:48 PM.

3. Implement Back-pressure and Circuit Breakers

Systems under stress shouldn’t accept unlimited work. AWS’s EC2 entered “congestive collapse” because it tried to process too much work simultaneously after recovery. Design systems that shed load gracefully and fail fast when overwhelmed.

4. Monitor for “Impossible” States

Observability must include monitoring for conditions that “should never happen.” In this case, Route53 referencing a non-existent plan should have triggered immediate alerts. I understand it’s easier said than done, but this level of monitoring is crucial for foundational services.

5. Design for Failure, Not Perfection

This race condition likely existed for years, passing all tests. No amount of testing can catch every edge case in distributed systems. Design with the assumption that failures will happen, and focus on quick detection and recovery.

6. Post-Mortems Are Investments, Not Overhead

What AWS Did Right: They published a detailed, transparent post-mortem in a short time, giving the community and industry an opportunity to learn from this incident. This transparency builds trust and advances the entire field of distributed systems engineering.
AWS link : https://aws.amazon.com/message/101925/

To summarise regional failures are extremely rare, and building systems to survive them involves significant cost trade-offs. However, for mission-critical systems, this incident raises important questions about dependency on a single cloud provider and the importance of multi-region architectures.

The question isn’t “How do we prevent all failures?”
The question is: “When the inevitable happens, how quickly can we recover?”

Thank you for your time reading the post.
On the journey to make cloud system design simple to understand and provide practical tips, please consider following if you wish to get notified!

What Went Wrong on the October 20th, 2025 AWS Outage? was originally published in AWS in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

When architecting scalable applications on AWS, understanding how Load Balancers, Target Groups, and Auto Scaling Groups works and how they integrate with each other is crucial. These three components form the backbone of resilient, highly available and scalable systems.

Lets understand each component and then different configurations they can have and then interesting stuff which is what are different cloud design patterns they contribute to.

Application Load Balancer — The Traffic Distribution Engine

There are three different types of load balancers however for this post we are going to focus on Application Load Balancer.
The Application Load Balancer (ALB) sits at the front, receiving incoming requests and intelligently distributing them across healthy targets. It operates at Layer 7 (HTTP/HTTPS) and provides advanced routing capabilities. ALB rules is the super power it has as it helps route based on conditions and single ALB can be use to distribute different types of traffic to different backend instances.

Key Configuration Options at ALB:

• Listeners: Define ports and protocols (HTTP:80, HTTPS:443)
• Routing Rules: Content-based routing using host headers, paths, HTTP methods
• SSL/TLS Termination: Handle certificates and offload encryption from backend instances
• Sticky Sessions: Route requests from specific users to the same target
• Cross-Zone Load Balancing: Distribute traffic evenly across all AZs.
• WAF Integration: Add Web Application Firewall protection.
• Cognito Integration: Handle user authentication at the load balancer level.
• Lambda Functions as Targets: Route requests directly to serverless functions.

Target Groups — The Routing & Health-Checks

Target groups is the bridge between the load balancers and your compute resources/instances.
They define where traffic should go and continuously monitor the health of registered targets. A target can be an EC2 instance, IP address, Lambda function, or even another Application Load Balancer.

The beauty of Target Groups is their flexibility — you can register targets manually or have Auto Scaling Groups manage this automatically. When an Auto Scaling Group launches a new instance, it automatically registers it with the associated Target Group. When scaling down, it handles the deregistration process automatically.

Key configurations at the target groups :

• Health Monitoring: Continuously checking if targets are healthy and can receive traffic.
• Request Routing: Determining which healthy target should receive each request based on the configured algorithm.
• Session Management: Maintaining stickiness when required for stateful applications
• De-registration Handling: Gracefully draining connections when targets are marked for removal
• Stickiness: Duration-based or application-controlled cookie stickiness

ALB-level stickiness applies uniformly to all target groups, while target group-level stickiness allows different configurations for each service/group of instances.

Auto Scaling Groups — The Scaling & Management Layer

Auto Scaling Groups ensure you have the right number of EC2 instances running at any given time. They automatically adjust capacity based on demand, health checks, or schedules. When attached to a Target Group, they create a self-healing, auto-scaling infrastructure.

The integration works like this: When an Auto Scaling Group launches a new instance, it automatically registers the instance with all attached Target Groups. The Target Group then begins health checking the new instance. Only after passing health checks does the instance start receiving traffic from the load balancer.

Key configurations at the auto scaling group level :

• Scaling Policies: Target tracking, step scaling, or simple scaling based on metrics
• Launch Templates: Define instance configuration including AMI, instance type, and user data
• Capacity Settings: Minimum, maximum, and desired capacity. (This is important)
• Warm Pools: Pre-initialized instances for faster scaling
• Lifecycle Hooks: Execute custom actions during scale-in or scale-out event.

Cloud Design patterns based on these 3 components

Pattern 1: Blue-Green Deployments

Gradually shift traffic between two application versions using weighted target groups.
Example: An e-commerce site deploys Black Friday features by routing 10% traffic to the new version, monitoring for issues, then incrementally increasing to 100%.

Pattern 2: Multi-Tier Architecture

Chain multiple load balancers where frontend ALB routes to internal NLBs for backend services.
Example : A banking app where the public ALB handles web traffic, routing to internal NLBs that distribute requests to transaction processing systems and account services.

Pattern 3: Cross-Region Failover

Combine Route 53 health checks with load balancers in multiple regions. Each region has its own ALB → Target Group → Auto Scaling Group stack. Route 53 monitors the health of each ALB and fails over traffic when needed.
Example: A streaming service maintains active stacks in US-East and US-West; if the East Coast data centre fails, Route 53 automatically redirects all viewers to West Coast servers.

Pattern 4: Hybrid Scaling Strategy

Configure multiple Auto Scaling policies: target tracking for normal operations (e.g., maintain 70% CPU utilization), scheduled scaling for predictable traffic patterns, and step scaling for rapid response to sudden spikes.
Example: A food delivery app scales on 70% CPU normally, adds capacity before lunch/dinner rushes (scheduled), and rapidly scales during unexpected viral promotions (step scaling).

Pattern 5: Container-Based Architecture

Register ECS tasks or EKS pods directly in Target Groups using IP target type. The container orchestrator handles registration/deregistration automatically as containers start and stop.
Example: A retail platform where each microservice (inventory, pricing, recommendations) runs in containers that automatically join their respective Target Groups as they scale.

Key Takeaways

The relationship between these three components is beautifully simple yet powerful, where load balancers only knows about the target groups not behind them, target groups manage the targets and their health and auto scaling groups has the ability to add or remove the instances in the target groups.

The integration of ALB, Target Groups, and Auto Scaling Groups creates a powerful, self-healing and self scaling infrastructure that can:
1. Automatically distribute traffic across healthy instances
2. Scale compute capacity based on demand
3. Maintain high availability across multiple failure domains
4. Provide sophisticated routing and health checking capabilities

Understanding these interconnections allows you to design robust, scalable applications that can handle varying loads while maintaining optimal performance and cost efficiency.

Remember: while the Load Balancer handles traffic distribution and Target Groups manage routing and health checks, it’s the Auto Scaling Group that brings the dynamic scaling magic to your infrastructure. Together, they form the foundation of scalable, resilient, modern cloud-native architectures on AWS.

Thank you for your time reading the post.
On the journey to make cloud system design simple to understand and provide practical tips, please consider following if you wish to get notified!

References

• AWS Auto Scaling Documentation
• Application Load Balancer User Guide
• Target Groups Configuration Guide
• Health Checks for ALB Target Groups
• Attaching Load Balancers to Auto Scaling Groups

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.

Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community. ❤️

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter.

And before you go, don’t forget to clap and follow the writer️!

load balancers, target group and auto scaling group how they are associated with each other and… was originally published in AWS in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Whenever someone hears “monolith,” the first reaction is usually, “No — that’s legacy, not modern.” That’s a quick stereotype. Here is my attempt to flip the script and introduce a different view: the “Modern Monolith.”

Over the last decade the microservices architecture has been on a rollercoaster ride. When microservices emerged, everyone raced to break apart big monoliths into dozens of small services. Cloud platforms made this easy, so teams copied standard microservice architecture template for new projects without fully weighing the trade-offs.
All this happened until Amazon Prime engineering team published a blog on how they moved some critical services back to monolith.

In this post I want to offer a different perspective on monoliths. I’m calling it a “modern monolith” — not a formal term, just a mental model to think about today’s monolithic apps differently.
The idea is — don’t dismiss “monolith” as legacy. A well-architected monolith — stateless, modular, event-driven, CI/CD-enabled — can deliver scalability and agility while avoiding the operational complexity of an overly fragmented microservice landscape.

Let’s break the debate into four questions:

Q. What is a Monolithic Architecture?
Q. What is a Microservices Architecture?
Q. What Went Wrong in Heavy Adoption of Microservices?
Embracing a “Modern Monolith” — best of both worlds

Q. What is a Monolithic Architecture ?

A monolithic architecture is a single, unified software system where most components share one codebase and one deployment artifact. Monoliths go way back — mainframes, early web apps and enterprise systems were monolithic by necessity. Containers, microservices, and elastic cloud scaling didn’t exist then.

Pros (early-stage / small-medium apps):

• Simplicity — one codebase, one deployable, straightforward local development.
• Performance — internal calls are in-process (no network hops).
• Faster initial delivery — less infra and orchestration overhead.

Cons (as it grows):

• Scaling limits — you scale the whole app, not just the hot path.
• Slower release cycles — rebuilding/redeploying the entire artifact.
• Maintainability — codebase complexity, long CI times, merge conflicts.
• Tech lock-in — upgrading frameworks or platforms affects the whole app.

Q. What is a Microservices Architecture?

A microservices architecture splits functionality into small, independent services. Each service runs in its own process, owns its data model (often its own DB), and communicates via APIs or messaging. This model rose to prominence in the 2010s with large-scale examples like Netflix and Amazon, who decomposed monoliths to scale teams and features independently.

Pros:

• Independent scaling per service.
• Resilience — faults are isolated.
• Team autonomy — smaller teams own services end-to-end.
• Technology choice per service.

Cons:

• Operational complexity — service discovery, observability, security, CI/CD for many services.
• Higher infra costs — many services mean more runtime, DBs, monitoring.
• Distributed debugging — tracing failures across services is harder.
• Data consistency difficulties — cross-service transactions get complex.

Q. What Went Wrong in Heavy Adoption of Microservices?

Microservices became a buzzword. Many teams adopted them for reasons like “we’ll grow big soon,” like Netflix, Amazon and Uber but without real evidence or the organisational maturity to manage them and actual projection needed.

Common failures:

• Premature decomposition. Splitting too early yields high operational cost without real benefit.
• Operational overhead. Teams underestimated the amount of platform work (observability, deployments, networking).
• Sprawl and cognitive load. Hundreds of tiny services become hard to manage, locate, and reason about.
• Cost surprises. More services often mean higher cloud bills and tooling costs.

In short: microservices solve real problems, but they bring a “complexity tax.” If you’re not paying that tax for clear gains (scale, independent life cycles, independent ownership), it’s usually the wrong move.

Embracing a “Modern Monolith” — best of both worlds.

Think of “modern monolith” as advanced version of “monolith”.
“Modern monolith” means treating a single deployable as a first-class, cloud-native app. Apply modern patterns inside the monolith so it becomes easier to scale, evolve, and split later if needed.

Key practices :

1. Stateless design —
   Keep the application stateless so multiple instances can run behind a load balancer. Push session/state to caches or stores (Redis, DynamoDB, etc.). That makes horizontal scaling simple — add identical nodes as load increases.
   success story — atlassian.com(reference link) .
2. Modular code organization —
   Structure code into clear modules or bounded contexts (orders, payments, customers). A modular monolith gives you the cognitive clarity of service boundaries while keeping a single deployable. Frameworks like Spring Modulith exist to help verify boundaries in a Spring Boot app.
   Example : Developers often use frameworks like Spring Modulith that let you define and verify domain modules within a single Spring Boot app. The advantages are clear: you still deploy one artifact, but your code is well-factored and in future when you need you turn that module into microservice.
3. Event-driven internally. Use domain events or an internal message bus to decouple modules. Rather than synchronous in-app calls.
   This reduces tight coupling and makes future extraction easier.
4. Best-of-cloud practices. Run the monolith in containers or VMs that can be scaled, and use platform services for things like caching, queues, and managed databases. Treat it like any cloud-native app. Leverage auto-deploy pipelines so that even a monolith can be continuously deployed. With modern CI/CD, even large monoliths can have quick, reliable releases if you have good test coverage and automation.
5. Selective microservice adoption. In a modern approach, you only split off services when there’s a clear need. For example, Prime Video kept its billing and content-management as separate microservices (where that made sense), but merged the performance-sensitive playback stack into a monolith. The core idea is: start with a monolith, refine it, then peel off genuinely independent pieces.

By doing this, you capture most microservices benefits (modularity, scalability) without most of the overhead. Atlassian’s own experience proves it. They moved Jira/Confluence to AWS as monolithic, stateless cloud apps first, then gradually carved out microservices as needed. ref — atlassian.com. Only after the apps were stable on the cloud did they break apart. This gave them scaling headroom up front and a smoother path to finer-grained architecture later.

How modern monoliths handle classic problems (scaling & reliability)

• Horizontal app scaling — make the app stateless, scale instances, and front them with a load balancer.
• Database bottlenecks — use read replicas, caching (Redis), CQRS for read-heavy workloads, and table partitioning/horizontal sharding when needed.
• Async processing — move long-running or CPU-heavy tasks to background workers (message queues, Lambda/functions, job runners).

Practical decision checklist: when to split into microservices

Consider extracting a module only when one or more of these are true:

• The module needs independent scaling and causes disproportionate infra cost if kept inside the monolith.
• The module has strongly different SLAs or security/compliance needs.
• The module’s team needs independent release cycles that block others.
• The module requires radically different technology that can’t co-exist cleanly in the same codebase.
• You have reliable metrics showing frequent incidents, latency, or deployment contention attributable to that module.

If none of the above are true — keep it in the modern monolith, but modularize it.

As Martin Fowler advises, nearly all successful microservice systems started as a modular monolith first. Only when that monolith hit real scaling or organizational limits should you peel off services. (ref — martinfowler.com).

Conclusion — pragmatic advice

Start with a well-factored, cloud-ready modern monolith. Make it stateless, modular, observable, and CI/CD-enabled. Optimize and measure. Only extract microservices when data (not hype) shows a clear benefit. A modern monolith is not a step backward — it’s a practical, low-risk starting point that lets you move fast and split later if you must.

Thank you for your time reading the post.
On the journey to make cloud system design more practical and simple to understand, please consider following if you wish to get notified!

references :
https://www.youtube.com/watch?v=9JPYCOpeDnY (Amazon prime case-study)

• Microservices vs. monolithic architecture | Atlassian
• Microservices vs. monolithic architecture | Atlassian
• 5 Advantages of Microservices [+ Disadvantages] | Atlassian
• bliki: Monolith First

When we think about load balancers, most of us immediately think “distribute traffic.” That’s true, but modern Application Load Balancers (ALBs) can do much more — and those extras are often very handy when designing system architecture.

Apart from distributing the load to downstream servers ALB also provides :

1. sticky session / sticky affinity .
2. content based routing
3. TLS offloading (a.k.a. TLS/SSL termination)

1. sticky session / sticky affinity .

There’s an increasing trend to design stateless backends — centralizing cache and session state — but some use cases still benefit from having a user hit the same backend instance for a period of time. ALB supports cookie-based stickiness (either using an ALB-generated cookie or your application’s cookie) so subsequent requests from the same client are routed to the same target.

Examples :
1) cart and checkout — on a busy e-commerce site, a user may keep a checkout session open while price checks and product comparisons happen. Sticky sessions can keep that user on the same server so local cache or in-memory session data improves latency for the checkout flow.

2) Gaming — game sessions often require low latency and frequently access per-player state in memory. Session affinity lets a player’s traffic stay pinned to the same backend instance for the duration of a match.

Notes / best practice: sticky sessions are useful for short-lived or transitional state, but for long-term scalability and resiliency you should move session state to a central store (Redis, DynamoDB, etc.). ALB stickiness is configurable (cookie duration), but relying on it as a permanent design for stateful apps can hinder scaling and rolling updates.

2. content based routing

This is a great ALB feature for microservices. Because ALB operates at Layer 7, it can inspect HTTP requests and route by host, path, headers, or query string — enabling a single ALB to front many services.

Examples :

1. Path-Based routing — An e-commerce application uses an ALB to route requests for browsing products (/products/*) to backend servers optimized for reading data, while requests for the shopping cart (/cart/*) go to servers that need to maintain state and open connections.

2. Host-based routing — A single ALB can host multiple domains or subdomains, routing contact.example.com requests to a customer support microservice and home.example.com requests to a general content service

3. Header-basesd routing- A request with a specific custom header, like X-API-Version: 2, could be routed to a newer version of an API service.

4. Query String routing- Routing requests based on specific query parameters, such as ?order=false, to a different backend service or target group than those that process requests with ?order=true.

3. TLS offloading (a.k.a. TLS/SSL termination)
TLS offloading means the ALB negotiates TLS with the client and decrypts traffic at the load balancer. You can then forward HTTP (cleartext) or re-encrypt to the backend over HTTPS.

TLS offloading is recommended on an Application Load Balancer (ALB) to improve server performance and efficiency by offloading the computationally intensive TLS encryption/decryption from backend application servers

Example end-to-end patterns :

• Pattern A — Simple (recommended)
  Route53 → ALB (HTTPS, ACM) —TLS terminated→ Private targets (HTTP)
  When to use: Simple, performant setup when you trust VPC traffic.
• Pattern B — End-to-end encrypted
  Route53 → ALB (HTTPS, ACM) —TLS terminated→ ALB re-encrypts → Targets (HTTPS with backend certs)
  When to use: Compliance or policy requires encryption to the host.

Apart from these top 3 (in my opinion), ALB also supports things like
1) health-checks of the target group by sending HTTP or HTTPS requests to registered targets to verify their health.
2) invoke lambda directly as a target in the ALB.
3) integrations with other services like — cognito, WAF which enhances the security further.
4) ALB also supports WebSockets/HTTP2, access logging, and routing rules that let you implement complex traffic shaping for microservices.

Thank you for your time reading the post.
On the journey to make cloud system design simple to understand and provide practical tips, please consider following if you wish to get notified!

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.

Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community. ❤️

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter.

And before you go, don’t forget to clap and follow the writer️!

Application Load Balancers — 3 Powerful Features Beyond Traffic Distribution was originally published in AWS in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently, I encountered a unique challenge that led me on an unexpected path of discovery.
Imagine this: we were trying to integrate a third-party application that used its own SMTP server. Our plan was to send emails using our email ID, salesagent@mydomain.com. This approach was crucial for maintaining trust with our customers and collaborators, making it seem as though the emails were coming directly from us, despite being sent through the third-party’s SMTP server.

It seemed simple at first. However, we soon faced a problem — emails sent through this setup were not reaching their destinations.
In the root cause analysis my usual focus was on application architecture and development, but this problem led me into uncharted territory which is DNS. DNS setting was the root cause behind our email issue, we deep dived into DNS tuned some configurations and it solved the problem.
All this turned into a fascinating exploration of how vital DNS settings are for ensuring emails sent from *@mydomain.com are recognized and delivered correctly. It highlighted the essential, yet often overlooked, role of DNS in our digital world.

What is DNS?

Ever wondered how typing a website address like google.com or gmail.com gets you to the right place? That’s where DNS, or the Domain Name System, comes into play.

Imagine DNS as the internet’s phonebook. It matches domain names to their corresponding IP addresses, much like how a phonebook pairs names with phone numbers. So, when you visit a website or send an email, servers around the world quickly direct your request to the right server IP address, all in the blink of an eye.

This process is quick, crucial, and ensures the internet operates smoothly. Let’s dive into how this critical yet unseen part of the internet works.

How DNS Works: The Basics quick dive

Ever typed ‘example.com’ and wondered how your browser knows where to go? That’s DNS for you — the internet’s phonebook. It’s like asking for directions and getting a precise location, say ‘192.0.2.1’, which your browser then uses to take you to your desired website. And guess what? If you visit often, your computer remembers the way, making the trip even faster next time, thanks to something called DNS caching.

There’s More to DNS

DNS isn’t just about turning names into numbers. It does offer couple of other important things,

• Load Balancing: Think of it as air traffic control for the internet, keeping websites up and running smoothly by spreading out visitor traffic.
• Redundancy and Failover: It’s like having a backup plan when a server takes a day off, directing users to others that are wide awake.
• Domain Management: DNS juggles all sorts of records, making sure emails find their way and websites know where to stand.
• Geographical Routing: It’s all about getting you there faster by connecting you to a server nearby.
• Security Features: Protecting against the internet’s version of prank calls with things like DNSSEC.
• Caching: Remembering your frequent stops to make revisits a breeze.

DNS Hierarchy Explained

“Let’s understand now how domain name is actually used by the DNS to resolve it to the IP, DNS hierarchy plays important role there. www.google.com

1. Root Level: At the top, we have the root servers. They guide our queries in the right direction, like signposts at a crossroads.
2. Top-Level Domains (TLDs): Next are the TLDs, like .com in www.google.com. The .com part tells us it’s a commercial website.
3. Second-Level Domains: Here’s where we find google in www.google.com. This is the domain name, the unique identifier chosen by the website owner.
4. Subdomains: Underneath that, we have subdomains. For example, www in www.google.com is a subdomain. It's commonly used to denote a website.

And don’t forget the dots! They’re like the spaces between words, helping to separate each part of the web address for clarity.

So, in www.google.com, we’re going from the general to the specific – starting from the type of domain (.com), moving to the unique name of the site (google), and specifying a particular service or page (www). It’s a neat, organized system that makes navigating the internet a whole lot easier."

DNS Records: The Basics

DNS records is like the easy understandable syntax using which configurations can be made for the DNS servers.
Out of others there are 4 absolutely essential DNS records types developer must know which are :

• A Record (Address Record): This is the backbone of the DNS system. A Records map a domain name to an IPv4 address. So when someone types in example.com, the A Record tells the DNS server which IP address to send them to.
  Example: example.com → 93.184.216.34
  Explanation: The A Record for example.com directs the browser to the IPv4 address 93.184.216.34.
• AAAA Record: Similar to the A Record, but it maps a domain to an IPv6 address, which is the newer IP address format designed to accommodate the vast number of internet devices.
  Example: example.com → 2606:2800:220:1:248:1893:25c8:1946
  Explanation: The AAAA Record for example.com points to the IPv6 address 2606:2800:220:1:248:1893:25c8:1946.
• CNAME Record (Canonical Name Record): Think of CNAME Records as aliases. If you have multiple subdomains like www.example.com and shop.example.com, and they point to the same IP address, you can use a CNAME record to redirect them to the primary domain name.
  Example: blog.example.com → example.com
  Explanation: The CNAME Record for blog.example.com redirects requests to the primary domain example.com.
• MX Record (Mail Exchange Record): This one is all about email. MX Records specify the mail server responsible for accepting email messages on behalf of a domain. It’s like a postal sorting office, directing where mail for a domain should go.
  Example: example.com → mail.example.com
  Explanation: The MX Record for example.com specifies that mail.example.com is the server handling its email traffic.

lets understand MX records using simple example ,

“Let’s say we have a fictional company named ‘SunnySideUp.com’ that just set up their email system. They’ve decided to use an email hosting service, like Microsoft 365, for handling their emails. Here’s how MX records come into play:

1. Setting Up the MX Records: When setting up their email with Microsoft 365, SunnySideUp.com is given specific MX records to add to their DNS settings. These records might look something like this:sunnysideup-com.mail.protection.outlook.com (Priority: 0)
2. How It Works: Now, imagine I’m sending an email to info@sunnysideup.com. My email service (let's say Gmail) will look up the MX records for 'SunnySideUp.com'. It finds the MX record pointing to Microsoft's email servers.
3. Email Routing: Gmail then sends my email directly to Microsoft’s email servers, as specified by the MX record. The priority ‘0’ in this case tells Gmail that this is the primary (and in our example, the only) server where emails should be delivered.
4. Email Reception: Microsoft’s servers receive my email and then process it, eventually delivering it to the inbox of info@sunnysideup.com.
5. Fallback Mechanism: If SunnySideUp.com had multiple MX records with different priorities, my email service would try the highest priority (the lowest number) first. If that server can’t be reached, it would then try the next one in line.

In this example, the MX record is essentially the signpost that tells any email sent to ‘@sunnysideup.com’ exactly where to go to get delivered. Without it, emails would be like letters sent without an address — they wouldn’t know where to go!”

Picking the Right DNS Provider

Leveraging DNS’s full suite isn’t a solo journey; there are standout services like Cloudflare and Amazon Route 53 ready to help. Cloudflare shines with its speedy and secure DNS management, while Amazon Route 53 boasts reliability and scalability. Both offer tools for everything DNS, from domain resolution to advanced security, all wrapped up in easy-to-use platforms.

Why Developers Should Know About DNS ?

Think of web hosting as the home for your website, a place where all the site’s information lives. DNS, or the Domain Name System, is like the sign that points people to your home when they type your website’s address, like example.com, into their browsers.
For anyone building web applications, knowing how to connect your site’s address to its online home(web hosted), and how to handle DNS settings, is super important. It makes sure your website is not just up and running but also easy to find and secure. Even just understanding the basics, such as how to set up where your website points or how emails are sent and received, can help you fix problems faster. I learned the hard way that not paying attention to DNS settings can lead to unexpected issues, like emails not being sent properly.

DNS in Application Development: Handy Tips

• Keep DNS Records Updated: It’s like letting everyone know you’ve moved to a new house so your mail doesn’t get lost.
• Use DNS Caching: This speeds up how fast your app works, similar to remembering a friend’s phone number to avoid looking it up all the time.
• DNS Load Balancing: This spreads out website visitors to prevent your app from crashing, much like having several lines open at a store checkout.
• Secure Your DNS: Protecting your DNS is crucial for keeping your app safe from online threats, just like locking your doors at night.

Navigating Common DNS Issues

Encountering problems with DNS can be frustrating, like hitting unexpected delays. For example, when you make changes to your DNS, it might take some time for everything to update across the internet — think of it as waiting for paint to dry. If your site isn’t showing up, double-checking your DNS settings is a good start, like making sure you dialed a phone number correctly. A small mistake in your DNS records can lead to big headaches, similar to dialing one wrong number in an important phone call. And if your site is slow, the issue might be with the DNS server, not your website itself, kind of like how traffic jams can slow you down even if your car is fine.

Conclusion

DNS might not get a lot of attention, but it’s crucial for making sure your online projects work smoothly. It does a lot more than just connect domain names to IP addresses; it affects how well your application performs, its security, and how reliable it is. Think of DNS as a helpful tool in your developer toolkit, guiding people to your app or website quickly and safely. Keeping your DNS settings in check is as essential as keeping your code clean and efficient.

Refecences :
https://blog.bytebytego.com/p/a-crash-course-in-dns-domain-name?utm_source=substack&utm_medium=email
https://www.packtpub.com/product/managing-mission-critical-domains-and-dns

Like many of you, I found ChatGPT magical at first — until I learned LLMs are just about predicting the next word, again and again, incredibly well.

“Advanced AI systems, particularly large language models, ‘understand’ text by predicting the next word in a sequence” — Geoffrey Hinton (The “Godfather of AI”)

“LLMs are ‘next word prediction system’” — Andrej Karpathy (Former OpenAI founding member, Tesla AI Director)

When leading AI personalities talk about LLMs, they often call them as “next word prediction systems.” There’s a reason for this, and it’s more profound than it sounds.

Let’s try to find answers for 3 keyq uestions about the GenAI:
Q. How does next-word prediction actually happen inside an LLM?
Q. Are GenAI and LLMs the same?
Q. Why is next-word prediction such a big deal — and how does it relate to “intelligence”?

Q. How does next-word prediction actually happen inside an LLM?

For simplicity, let’s break down the LLM pipeline into four main blocks, across two phases:

• Training phase: Here the model learns by analyzing massive amounts of text, adjusting itself to better predict the next word.
• Inference phase: Here the trained model generates responses to user prompts, using what it has learned to predict the next word in real time.

(Except for “Verify Predictions,” all blocks are used in both phases.)

If you fancy going deep please check here.(3+hours long video but worth the time). Also have a look over this white paper.
In this blog I am trying to put key things learned from above resources which are essential for any software developer, architect.

Continue reading further to get the gist of important components.

BLOCK 1: READ TEXT — Converting human language into machine-understandable format

1) Tokenization: Breaking text into smaller units (tokens) that the model can process. Example: “Let’s learn about AI” → [“Let”, “‘s”, “learn”, “about”, “A”, “I”].

2) Vector Embeddings: Each token is converted into a vector (a list of numbers) capturing its meaning. E.g., “dog” and “puppy” get vectors close together in space.

3) Positional Encoding: Adds information about word order. For example, “dog bites man” ≠ “man bites dog” — positional encoding helps the model know the difference.
Vector embeddings put the tokens on their specific area howevver positional encoding further enhance their location looking at the “position” in any specific sentense.

Flow: Raw text → Tokenisation → Token IDs → Vector Embeddings → Position-aware representations.

Understanding basics of Tokenization and vector embeddings is crucial if you are looking to develop any GenAI/ LLM application.

BLOCK 2: PREDICT WORD — The core engine

1. Transformer: Architecture that processes token sequences in parallel. Example: Processing “The capital of France is” all at once to predict “Paris”. Think of it as a super-flexible neural network specialised for sequences.

Do you know google translations transformer architecture model is at the heart of all modern LLMs ?

2) Self-attention: Mechanism allowing tokens to “see” other tokens in the sequence. Example: “The cat sat on the mat because it was soft,” “it” refers to “mat” — self-attention helps the model figure that out.

3) Multi-head Attention: Running self-attention multiple times in parallel to capture different relationships.
Example: One head focuses on grammatical structure while another captures topical relationships.

Attention steps are where LLM start becoming intelligent, learning different meanings, intention behind the sentences like we do.

4) Feed-Forward: Neural network layer processing each token position independently.
Example: After tokens interact through attention, feed-forward networks transform each position’s representation individually.

Flow: Input embeddings → Self-Attention → Multi-head Attention → Feed-Forward → Output probabilities for next token

BLOCK 3: VERIFY PREDICTIONS — Learning and improvement mechanisms

1) Training: Process of learning from examples.
This is interesting in this model is trained on the available data until it predicts known facts right.
Example: Model reads billions of text examples to learn language patterns.

2) Loss Calculation: Measuring prediction accuracy. Example: If model predicts “dog” with 70% confidence when correct word is “cat”, it calculates how wrong this prediction was.

3) Back-propagation: Sending error signals backward to adjust weights. Example: If “river” was incorrectly predicted after “The boat sailed down the”, parameters are adjusted to better predict “river” in similar contexts.

4) Fine-Tuning: Refining a pre-trained model for specific tasks.
Example: Taking a general model and further training it on medical literature for healthcare applications.

Flow: Predicted word vs. Actual next word → Calculate error → Adjust model parameters → Improve future predictions

All big companies are racing to secure powerful GPU machines to keep doing propagation on their models before launching model to the public, so that they keep on improving the Accuracy of the “next” word.

BLOCK 4: ENHANCE UNDERSTANDING — Continuous improvement and knowledge integration

1) Inferencing: This is to use trained model to generate text based on new prompts.
Example: Given prompt “Write a poem about”, model generates most likely continuation based on training.

2) Context Processing: This Keeps track of conversation history or document context to generate relevant answers.
Example: Remembering user mentioned “my dog Max” earlier when responding to “What’s his favorite food?”

3) Temperature/Sampling: Controls randomness in word choice. Low temperature = safer, more predictable answers; high temperature = more creative, surprising outputs.
Example: Low temperature (0.3) gives predictable responses like “2+2=4” while higher temperature (0.8) might produce more creative or varied text.

Flow: Apply learned patterns → Generate coherent responses → Demonstrate understanding of context, reasoning, and world knowledge

Unified Analogy for All 4 Blocks

Think of the 4-block framework like a detective solving a complex case:
Imagine the LLM as a detective piecing together a story:

Block 1 (Read Text) is the evidence collection phase.

• Tokenization is like breaking down witness statements into key facts
• Vector embeddings are connecting these facts to existing knowledge (like linking a witness description to known suspects)
• Positional encoding is establishing the timeline of events (knowing that event A happened before event B is crucial)

Block 2 (Predict Word) is forming theories and connections.

• The transformer is the detective’s mind processing all evidence simultaneously
• Self-attention is making connections between separate pieces of evidence (“this fingerprint matches this suspect”)
• Multi-head attention is examining evidence from multiple angles (forensics, motive, opportunity)
• Feed-forward networks are developing conclusions from these connections

Block 3 (Verify Prediction) is testing theories against reality.

• Training is the detective’s years of experience solving cases
• Loss calculation is measuring how far off a theory was from what actually happened
• Back-propagation is adjusting investigative methods based on solved cases, facts.
• Fine-tuning is specialising in particular types of cases (like cybercrime or homicide)
• Inferencing is applying experience to new cases
• Context processing is keeping track of all relevant case details
• Temperature/sampling is deciding whether to stick to just the facts or include speculative elements when presenting findings

Q. Is GenAI and LLM the same?

Think of GenAI (Generative AI) as the whole toolbox, and LLMs (Large Language Models) as just one tool inside.

• LLM: Specializes in generating and understanding text (e.g., ChatGPT writing an email).
• GenAI: Includes LLMs, but also covers image generators (like DALL-E), music generators, code assistants, and more.

Example:

• LLM: Writes a poem about the moon.
• GenAI: Writes a poem (LLM), draws a picture of the moon (image model), and composes a moon-inspired melody (music model).

All LLMs are GenAI, but not all GenAI are LLMs.

Q. Why predicting the next word is a big deal & how it relates to generated intelligence

It’s the secret sauce. By learning to predict the next word, the model absorbs grammar, facts, logic, and even creativity. That’s why Hinton and Karpathy emphasize it: “next-word prediction”, done at scale, leads to emergent intelligence.

When you chat with an LLM, every answer is just the sum of thousands of next-word predictions — each one informed by all the knowledge and context the model has seen.

“Next word prediction” sounds simple, but it’s the engine behind LLM intelligence. As Geoffrey Hinton points out, this task pushes models to build deep internal representations of language, facts, and reasoning.
For example, when GPT completes “The capital of France is” with “Paris,” it’s showing knowledge. Or, when it finishes “To bake a cake, you need flour, sugar, and” with “eggs,” it’s showing common sense.

As Andrej Karpathy explains, “The model is forced to develop a compressed representation of everything humans have written down.” The prediction task creates pressure to understand syntax, semantics, facts, logic, and even cultural nuances.

LLMs may seem magical, but their power comes from a simple, relentless process: predicting the next word, over and over, with context and knowledge. That’s what turns data into intelligence.

________
References
https://www.youtube.com/watch?v=7xTGNNLPyMI&t=558s
https://proceedings.neurips.cc/paper_files/paper/2017/file/3f5ee243547dee91fbd053c1c4a845aa-Paper.pdf
https://www.vellum.ai/blog/genai-vs-llm-breaking-down-the-basics-and-useshttps://bbycroft.net/llm

__________

Thank you for your time reading the post.
On the journey to understand the core essence of Generative AI, Agents and its practical usage in Application Development, please consider following if you wish to get notified!
__________

Imagine you’re visiting Buckingham Palace, where different guests are charged different entrance fees. Just like the Palace doesn’t tie its visitors to specific rooms, we can add “visitors” to our classes without binding them to our objects. So, while the Palace handles each guest differently, our code can do the same .

Visitor Design Pattern is a behavioral design pattern.
The main intent behind the pattern is to allows us to add new operations to existing object structures without modifying the structures themselves. It’s particularly useful when we have a complex object hierarchy, and we want to perform various operations across objects of different types.

Example scenario :
Imagine an eCommerce platform where you have different types of products: Books and Electronics etc. You want to perform different operations on these products, such as calculating shipping costs and applying discounts. Instead of adding these operations directly to the Book and Electronics classes, we can use the Visitor pattern to separate these operations.

By doing this, we have a choice of adding the new operation on the object only on those objects we want and also we have separated the related algorithm(logic) to completely separate class, hence separation of concern is achieved.

UML class diagram

When a visitor (e.g., ShippingCostVisitor) is passed to a product's accept method, the product calls the appropriate visit method based on its type.

UML Sequence diagram

Implementation details :
Here the key is to implement the different VisitorClasses and make our Products accept the Visitor(VisitorClasses) using respective hirarchies.

*** other classes please refer the git repo link mentiond below 

class ShippingCostVisitor implements Visitor {
    private double shippingCost;

    @Override
    public void visit(Book book) {
        shippingCost = book.getWeight() * 0.5; // Example: $0.5 per unit weight
    }

    @Override
    public void visit(Electronics electronics) {
        shippingCost = electronics.getWeight() * 1.5; // Example: $1.5 per unit weight
    }

    public double getShippingCost() {
        return shippingCost;
    }
}

**

public class Main {
    public static void main(String[] args) {
        Product book = new Book(20, 2); // $20, 2 kg
        Product laptop = new Electronics(1000, 5); // $1000, 5 kg

        // Calculate shipping cost
        ShippingCostVisitor shippingVisitor = new ShippingCostVisitor();
        book.accept(shippingVisitor);
        System.out.println("Book Shipping Cost: $" + shippingVisitor.getShippingCost());

        laptop.accept(shippingVisitor);
        System.out.println("Laptop Shipping Cost: $" + shippingVisitor.getShippingCost());

        // Apply discount
        DiscountVisitor discountVisitor = new DiscountVisitor();
        book.accept(discountVisitor);
        System.out.println("Book Discount: $" + discountVisitor.getDiscount());

        laptop.accept(discountVisitor);
        System.out.println("Laptop Discount: $" + discountVisitor.getDiscount());
    }
}

Please check this github link for complete code.
https://github.com/adityachaudhari24/DesignPatternsJava/tree/master/visitor-pattern

When to use this patter?
Cleaning Up Logic: Use the Visitor to clean up and separate additional behaviors from the core business logic, making your codebase more maintainable.

Selective Behavior: Use the pattern when a behavior applies only to certain classes within a hierarchy, allowing you to implement it without cluttering unrelated classes.

Comparing visitor with other patterns
Visitor vs. Strategy:

• Strategy focuses on swapping algorithms or behaviors at runtime, encapsulating them within interchangeable objects.
• Visitor focuses on performing operations across a structure of objects without changing their classes, making it ideal for adding new operations.

Visitor vs. Command:

• Command encapsulates a request as an object, allowing for parameterization and queuing of operations.
• Visitor is more about structuring operations that need to be performed on elements of an object hierarchy, without modifying the elements themselves.

Visitor vs. Decorator

• Visitor: Adds new operations to a group of related classes without altering their structure. It’s particularly useful when you need to perform different operations on elements within a complex object hierarchy.
• Decorator: Adds or overrides behavior in individual objects dynamically. It wraps objects to extend or alter their functionality without modifying the object itself.

Visitor vs. Composite:

• Composite organizes objects into tree structures, allowing clients to treat individual objects and compositions uniformly.
• Visitor operates on these tree structures, enabling you to apply new operations across the composite structure without altering the component classes.

Summary
The Visitor Design Pattern is a powerful tool for adding new operations to complex object structures without modifying their classes. It’s ideal for scenarios where you need to apply different operations across various types of objects.
Visitor stands out for its ability to operate across object hierarchies, adding new behaviors without cluttering existing classes.

Visitor design pattern — get the gist in 2 min was originally published in JavaDeveloperDiary — JDD on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since few months now i have been exploring design patterns from GOF and head-first books and trying to write 2 min post and long 5–10 min post.
In this post concluding the series of all those articles along with simple to understanding one liners.

Creational design pattern gives you a lot of flexibility in what gets created, who creates it and how it gets created and when.
Below are important types of Creational desing pattern :

1. Factory method pattern :
   one liner :”Let subclasses decide which objects to create.”
   Factory method pattern defines an interface for creating an object but lets the subclass decide which class to instantiate.
   Further reference : https://medium.com/javadeveloperdiary-jdd/factory-method-pattern-get-the-gist-in-2-min-720f875142ba
2. Singleton Pattern
   one liner :”only one item to rule them all.”
   The singleton pattern ensures a class has only one instance, and it provides a global point of access to it.
   Further reference : https://medium.com/javadeveloperdiary-jdd/singleton-design-pattern-get-the-gist-in-2-min-445539d4cf14
3. Prototype Pattern
   one liner :”Clone and customize, a blueprint in action”
   With the Prototype pattern, you can create new objects by cloning existing ones, saving time and reducing the potential for errors.
   The Prototype design pattern allows us to create new objects by cloning existing ones, rather than by creating them from scratch.
   Further reference : https://medium.com/javadeveloperdiary-jdd/prototype-design-pattern-get-the-gist-in-2-min-265ddaf7efa7
4. Builder Pattern
   one liner :”Step by step build it right”
   The intent behind the Builder Design Pattern is to separate the construction of a complex object from its representation so that the same construction process can create different representations.
   Further reference : https://medium.com/javadeveloperdiary-jdd/builder-pattern-get-the-gist-in-2-min-7c6befd0515d

Structural patterns are concerned with how classes and objects are composed to form large structures.
Below are important types of the structural design patterns

1. Adaptor Pattern
   one liner :”Bridging the gaps between incompatible interfaces, making them work together seamlessly ”
   Adaptor pattern converts the interface of a class into another interface clients expect. The adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. This is done simply by adapter implementing the interface of one object and wrapping another object.
   Further reference : https://medium.com/javadeveloperdiary-jdd/adapter-pattern-get-the-gist-in-2-min-f1fcad7d706d
2. Composite Pattern
   one liner :”Treating individual and group objects uniformly, forming a unified structure with hierarchical relationships.”
   It’s about composing different objects of a similar family (interface) and then appearing them as one for an external client. Each object in the composition may or may not have child objects.
   Further reference : https://medium.com/javadeveloperdiary-jdd/composite-design-pattern-get-the-gist-in-2-min-cffcbe5953
3. Decorator Pattern
   one liner :”Adding new functionalities dynamically, enhancing an object’s behavior without altering its core implementation”
   In simple words, the decorator pattern helps attach different behaviors to the object at the runtime by wrapping the object with a specific type of wrapper class which contains the new behavior logic.
   Further reference : https://medium.com/javadeveloperdiary-jdd/decorator-pattern-get-the-gist-in-2-min-3a3f84d85f38
4. Proxy Pattern
   one liner :”Acting as a representative or surrogate for another object, controlling access and providing additional functionality when needed.”
   Think of a proxy pattern when you want to add an extra layer of indirection to access a resource or control access to it. It is useful in scenarios where you would want to improve performance by caching frequently used objects, reduce network traffic by implementing lazy loading, or provide a simplified interface to a complex system.
   Further reference : https://medium.com/javadeveloperdiary-jdd/proxy-design-pattern-java-get-the-gist-in-2-min-684adff7b077

Behavioral design patterns intent to focus on communication and interaction between objects, defining how they collaborate and distribute responsibilities.
Use: These patterns are used to manage complex object interactions, providing flexible communication patterns.

1. Template method Pattern
   one liner :”Follow the blueprint, customize the details”
   The main intent behind the template method pattern is to provide the skeleton of an algorithm in the parent class and let subclasses extend the parent and define fill-ins by overriding methods. Well, the interesting part is that though algorithm fill-ins are implemented in the subclasses they are called by the parent class. Only parent calls those methods from subclass and this is called as famous “ Don’t call us, we will call you” Principle.
   Further reference : https://medium.com/javadeveloperdiary-jdd/template-method-pattern-get-the-gist-in-2-min-8cad25087564
2. Strategy Pattern
   one liner :”Switch it up choose the best approach”
   All intent behind the strategy pattern is to encapsulate behaviors that belongs to a similar purpose and make them interchangeable .
   Further reference : https://medium.com/javadeveloperdiary-jdd/strategy-pattern-java-get-the-gist-of-it-in-2-min-b8ed180b1c43
3. Command Pattern
   one liner :”Wrap it up, encapsulate object for further reference”
   The Command Design Pattern is all about encapsulating a request as an object and passing it as a request parameter. It decouples the object that invokes the action from the object that performs the action.
   Further reference : https://medium.com/javadeveloperdiary-jdd/command-pattern-get-the-gist-in-2-min-14a5a7dface2
4. Observer Pattern
   one liner :”Stay in sync, get notified when things change.”
   The basic idea behind observer pattern is to have a publisher — subscriber like mechanism , where publisher wants to notify multiple subscriber objects regarding some events / state change which is the in interest of subscriber.
   Further reference : https://medium.com/javadeveloperdiary-jdd/observer-pattern-get-the-gist-in-2-min-49d5f0afe6b0
5. Iterator Pattern
   one liner :”Take it step by step, explore a collection one element at a time.”
   Iterator pattern is all about streamline the access of the collection so that the client which want to iterate over collection must not worry about entire collection instead it just check if list hasNext() element and call next() element.
   Further reference : https://medium.com/javadeveloperdiary-jdd/iterator-pattern-get-the-gist-in-2-min-51ba536bf996

Learning is a never-ending journey that brings constant satisfaction through multiple milestones.
Here at this point concluding the 2 min series of design patterns but with the promise to come up with more such simple to understand posts related to enterprise application development.
Please also check https://www.adityatechinsights.com/series/design-patterns for detail insights for the design patterns and future posts.

Thanks for reading ! Happy coding !

Design Patterns — get the gist in 2 min concluding series with easy to remember one liners on each… was originally published in JavaDeveloperDiary — JDD on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to a world of software development without copy-paste ‼!
Just imagine the nightmare it would be — every time you needed to reuse a piece of code, you would have to manually retype it every single time. Thankfully, we live in a world where copy-paste is a widely accepted practice (without violating the copyright principles ofcource), as programmers, we are always on the lookout for better and more efficient solutions.

here is the Prototype Design Pattern — a pattern that offers a more elegant and flexible alternative to copy-paste. With the Prototype pattern, you can create new objects by cloning existing ones, saving time and reducing the potential for errors.

The Prototype design pattern is a creational pattern that allows you to create new objects by cloning existing ones, rather than by creating them from scratch.

Simple Example
Let’s say we have an online store that sells customized t-shirts. Customers can choose the color, size, and design of the t-shirt.
1. To avoid creating new instances for all the variants we are thinking to
provide a way for the backend to use a base variant and then customize
that base Tshirt and then add that to the cart.
2. Customers can also choose OLD orders, and choose Tshirt from that order as a base variant, modify it and add to the cart.

To keep the brevity adding only main method here please refer entire github code here [github link]

public class Main {
    public static void main(String[] args) {
        // Create a prototype t-shirt our base default variant
        TShirt prototype = new TShirt("red", "M", "logo", 24.99);

        // Create an order for 3 t-shirts
        //Order order = new Order(prototype, 3);

        // Get a clone of the prototype t-shirt
        try {

            TShirt tShirt = prototype.clone();
            // Customize the t-shirt
            tShirt.setColor("blue");
            tShirt.setSize("L");
            tShirt.setDesign("text");
            tShirt.setPrice(29.99);

            // Add the customized t-shirt to the cart
            Cart cart = new Cart();
            cart.addItem(tShirt);
            System.out.println("\nPrinting items in the cart ");
            cart.printItems();


            // cloning the product from the OLD order, modify it and then modified product to the cart
            // Create a prototype t-shirt our base default variant  which belongs to the old order
            TShirt oldOrderTSHIRT = new TShirt("black", "L", "Name", 26.99);

            // Create an order for 3 t-shirts
            Order order = new Order(oldOrderTSHIRT, 3);

            // in the getShirt , its providing the cloned object .
            TShirt tShirt2 = order.getTShirt();
            // Customize the t-shirt
            tShirt2.setColor("blue");
            tShirt2.setSize("L");
            tShirt2.setDesign("Name");
            tShirt2.setPrice(26.99);

            // adding Tshirt to the cart
            cart.addItem(tShirt2);
            System.out.println("\nPrinting items in the cart ");
            cart.printItems();

        } catch (CloneNotSupportedException e) {
            e.printStackTrace();
        }

    }
}
***********************************
OUTPUT 
Printing items in the cart 
text t-shirt, L, blue: $29.99

Printing items in the cart 
text t-shirt, L, blue: $29.99
Name t-shirt, L, blue: $26.99
***********************************

The Prototype pattern is commonly used in situations where many objects with similar properties need to be created quickly and efficiently. This includes scenarios such as creating product catalogs, generating reports, and creating user profiles in a social network.

The Prototype pattern has real-world applicability in scenarios where there are many objects with similar properties that need to be created quickly and efficiently, and where object creation is expensive or time-consuming. The pattern has several benefits, such as reducing the amount of time and resources required to create new objects, promoting code reusability, and allowing for dynamic modification of objects

In Java Cloneable marker interface is provided to clone an object using the prototype principles.
Also if you have come across prototype scope in spring, the prototype scope is based on the Prototype pattern and allows you to define a bean as a prototype, which means that a new instance of the bean will be created each time it is requested.

The real fun is in the details, if you wish to know and understand different styles of strategy pattern and java code examples, pros-cons, please consider visiting my detailed article at [prototype-pattern-java-explained-7-min-read]

Thanks for reading. Love IT, Live IT, Enjoy IT.

On the journey to understand the core essence of design patterns.
Every Tuesday publishes a small 2 min post and a long 5–10 min post along with a code example, please consider following if you wish to get notified!

Prototype design pattern — get the gist in 2 min. was originally published in JavaDeveloperDiary — JDD on Medium, where people are continuing the conversation by highlighting and responding to this story.

The intent behind the Builder Design Pattern is to separate the construction of a complex object from its representation so that the same construction process can create different representations.
It’s a type of creational design pattern.

This is useful when we need to create objects that have multiple options or configuration settings, Instead of having a constructor with a long list of parameters that are difficult to manage and remember, the Builder pattern provides a more organized and flexible approach.

Using the Builder pattern allows you to create objects step by step, with each step adding more options or configurations. The final result is an object that is fully configured and ready to use.

Structure of the builder pattern

In the above UML class diagram, the Director class doesn't create and assemble the ProductA1 and ProductB1 objects directly. Instead, the Director refers to the Builder interface for building (creating and assembling) the parts of a complex object, which makes the Director independent of which concrete classes are instantiated (which representation is created). The Builder1 class implements the Builder interface by creating and assembling the ProductA1 and ProductB1 objects.

Simple Example
In the below code, we are creating the Car object using the Builder pattern.
This is the method chaining builder pattern implementation where each method in the builder class returns the Builder instance.

public class Car {
    private String model;
    private String color;
    private int year;

    public static class Builder {
        private String model;
        private String color;
        private int year;

        public Builder() {}

        public Builder setModel(String model) {
            this.model = model;
            return this;
        }
        public Builder setColor(String color) {
            this.color = color;
            return this;
        }

        public Builder setYear(int year) {
            this.year = year;
            return this;
        }

        public Car build() {
            return new Car(this);
        }
    }

    private Car(Builder builder) {
        this.model = builder.model;
        this.color = builder.color;
        this.year = builder.year;
    }

    public String getModel() {
        return model;
    }

    public void setModel(String model) {
        this.model = model;
    }

    public String getColor() {
        return color;
    }

    public void setColor(String color) {
        this.color = color;
    }

    public int getYear() {
        return year;
    }

    public void setYear(int year) {
        this.year = year;
    }
}

*****
package com.ecommercearchitect.designpatterns.builder.methodchainingexample;

public class BuilderMethodChainingExampleMain {
    public static void main(String[] args) {
        Car car = new Car.Builder().setModel("Honda Civic").setColor("Red").setYear(2021).build();
        System.out.println(car.getModel()); // output: Honda Civic
        System.out.println(car.getColor()); // output: Red
        System.out.println(car.getYear());  // output: 2021
    }
}

**** OUTPUT ****
Honda Civic
Red
2021

StringBuilder and StringBuffer classes in Java are used to implement the Builder pattern, allowing you to append strings and other data types to build a final string which is Immutable.

The real fun is in the details, if you wish to know and understand the pros-cons, java-code examples then please consider checking the detailed article at [builder-pattern-explained-8-min-read]

Thanks for reading. Love IT, Live IT, Enjoy IT.

On the journey to understand the core essence of design patterns.
Every Tuesday I publish a small 2 min post and a long 5–10 min post along with a code example, please consider following if you wish to get notified!

Builder pattern — get the gist in 2 min was originally published in JavaDeveloperDiary — JDD on Medium, where people are continuing the conversation by highlighting and responding to this story.