DEV Community: Mohamed El Laithy

Java 27 in 10 Minutes — What Actually Changed

Mohamed El Laithy — Thu, 10 Sep 2026 08:49:41 +0000

Java 27 shipped in September 2026. It's a non-LTS release, so most production teams will skip it and stay on Java 25 LTS, but a few of the defaults it ships are worth knowing about even if you never install it.

G1 is now the only default GC (JEP 523). Small/constrained JVMs used to silently get Serial GC instead
Object headers shrink from 96 bits to 64 bits, on by default (JEP 534). Real measured savings, not a flat percentage (details below)
TLS 1.3 gets quantum-resistant key exchange, on by default (JEP 527). Zero code changes for most apps
Pattern matching finally works on primitives (JEP 532, 5th preview). switch (int) with guards, no boxing
Structured Concurrency, Lazy Constants, Vector API all get another preview/incubator round (JEP 533, 531, 537)

No huge syntax additions this cycle. It's mostly two years of JDK 25 experiments getting switched on by default. Here's what that means for code you actually run.

G1 everywhere (JEP 523)

Before 27, GC selection depended on your machine's CPU count and memory at JVM startup. Constrained environments, think a 1-CPU container, could end up on Serial GC without anyone choosing it:

$ java -XX:ActiveProcessorCount=1 -Xmx256m -Xlog:gc -version
[0.006s][info][gc] Using Serial

That's a real capture, not hypothetical. I ran it. On Java 27, the same command reports Using G1, unconditionally. If you were relying on Serial's lower overhead for a sidecar, -XX:+UseSerialGC still works; it just stops being a default you get without asking.

Compact Object Headers, and the part nobody explains (JEP 534)

The pitch: header size drops from 96 bits (12 bytes) to 64 bits (8 bytes), and the JEP cites 10 to 20% less heap for typical workloads. True, but incomplete. HotSpot rounds every object up to an 8-byte boundary, so the saving only shows up when the smaller header crosses that boundary.

I benchmarked five tiny classes (0 to 4 int fields, 10M instances each) with MemoryMXBean, once per header mode:

Fields	Standard header	Compact header	Saved
0 ints	16.00 B	8.00 B	-50%
1 int	16.01 B	16.00 B	0%
2 ints	24.00 B	16.00 B	-33%
3 ints	24.00 B	24.00 B	0%
4 ints	32.00 B	24.00 B	-25%

A clean sawtooth. The win shows up exactly where the header saving pushes an object across a rounding boundary the standard header didn't, and vanishes where both land on the same boundary. If you're allocating millions of small objects, re-run this against your own classes before assuming "10 to 20%" applies to you.

javac -d out src/HeaderSizeBench.java
java -Xmx4g -cp out HeaderSizeBench                              # standard headers
java -Xmx4g -XX:+UseCompactObjectHeaders -cp out HeaderSizeBench # compact headers

(Finalized since JEP 519 in JDK 25, no experimental flag needed anymore.)

Post-quantum TLS, and proving it's not in 25 yet (JEP 527)

TLS 1.3 now negotiates a hybrid key exchange, classical ECDHE plus NIST-standardized ML-KEM, automatically, whenever both peers support it. The motivation is "harvest now, decrypt later": someone can record your encrypted traffic today and decrypt it once quantum hardware exists, so the defense has to ship before the threat is fully real.

I didn't just take the JEP's word for it. Real handshake, real server:

attempt("default groups (control)", factory, host, null);
attempt("X25519MLKEM768 only", factory, host,
        new String[]{"X25519MLKEM768"});
attempt("X25519MLKEM768 + x25519 + secp256r1 (fallback)", factory, host,
        new String[]{"X25519MLKEM768", "x25519", "secp256r1"});

[default groups (control)                  ] SUCCEEDED -- TLSv1.3, TLS_AES_256_GCM_SHA384
[X25519MLKEM768 only                       ] FAILED -- SSLHandshakeException: (handshake_failure)
[X25519MLKEM768 + x25519 + secp256r1 (fallback)] SUCCEEDED -- TLSv1.3, TLS_AES_256_GCM_SHA384

That's JDK 25. The hybrid group isn't implemented yet, so asking for it alone fails outright. Asking for it with a classical fallback succeeds and just negotiates down. That's the whole migration story: list a classical group alongside the PQC one until you've confirmed both ends of a connection support it.

Pattern matching on primitives (JEP 532, 5th preview)

The one actual language feature this cycle. switch and instanceof can match primitive types directly now, guards included, no boxing:

int score = 82;
switch (score) {
  case int s when s >= 90 -> System.out.println("excellent");
  case int s when s >= 75 -> System.out.println("good");
  default                 -> System.out.println("needs work");
}

Still preview (--enable-preview required), and it's been through five rounds of feedback already, so don't treat the exact syntax as locked in.

Everything else, briefly

Structured Concurrency, 7th preview (JEP 533): this round throws ExecutionException instead of a custom type, and onTimeout() is renamed timeout().

Lazy Constants, 3rd preview (JEP 531): adds Set.ofLazy().

Vector API, 12th incubator (JEP 537): API unchanged this cycle (still waiting on Valhalla), but I ran a real scalar-vs-vector dot-product benchmark on it: about 2.0x measured speedup with 512-bit AVX-512 vectors. Not 16x, because the kernel is memory-bandwidth-bound at that array size, not compute-bound. Worth understanding before you reach for jdk.incubator.vector expecting a free 16x.

Should you upgrade?

If you're on Java 21 or 25 LTS in production, there's no reason to move yet. Track these features for your next LTS jump. If you're on a personal project or want to try quantum-resistant TLS early, go for it, just don't ship --enable-preview code to production.

I wrote all of this up with the full release timeline, glossary, and a longer walkthrough as a free PDF, grab it here, no signup wall. If you find it useful, a review helps other people find it. I've also got real, benchmarked deep-dives on the Vector API and Compact Object Headers numbers above with the full code and methodology, at mellaithy.gumroad.com.

Check out the key changes in Java 27 and what they mean for Java developers.

Happy to answer questions on any of this in the comments, especially if you've run these benchmarks on different hardware and gotten different numbers. I'd like to compare.

The 4-Second API: How a Hidden N+1 and a Blocking HTTP Call Took Down Our Order Service

Mohamed El Laithy — Tue, 08 Sep 2026 06:52:49 +0000

High latency with idle CPU is not a mystery — it's a diagnosis. A P1 post-mortem on connection pool starvation in Spring Boot.

A P1 post-mortem on connection pool starvation in Spring Boot, and the three unglamorous fixes that brought p95 latency from 4.2s back to single digits.

The alert nobody wants at peak hour

Traffic was normal. Around 2,000 requests per minute. No deploy had gone out that day.

Then the dashboards lit up:

p95 latency: 180ms → 4,200ms
HikariCP saturation alerts firing continuously (pool size: 10)
CPU under 40% across every pod
~3% of responses returning orders with missing line items
A mix of raw 500 stack traces and empty 200s going out to clients

That third bullet is the one that told us what kind of problem we had.

If the CPU is idle while latency explodes, nobody is computing anything. Threads are sitting still, blocked on I/O, waiting for something that isn't coming back fast enough.

So the question stopped being "what's slow" and became "what are we waiting on, and why are we holding a database connection while we wait."

Root cause: one endpoint, three anti-patterns

Everything traced back to a single controller method. Here is what was actually running in production:

@GetMapping("/orders/{userId}")
public List<OrderDTO> getOrdersByUser(@PathVariable Long userId) {
    List<Order> orders = orderRepository.findByUserId(userId);
    List<OrderDTO> result = new ArrayList<>();

    for (Order order : orders) {
        OrderDTO dto = new OrderDTO();
        dto.setId(order.getId());
        dto.setStatus(order.getStatus());

        // Triggers N+1: lazy loading inside the loop
        dto.setItems(order.getItems());

        // A synchronous 350ms HTTP call. Inside the same loop.
        dto.setPaymentStatus(paymentClient.getStatus(order.getId()));

        result.add(dto);
    }
    return result;
}

It reads fine. That's the problem with this class of bug: it passes code review, it passes tests against a seeded database with three orders, and it falls apart the moment a real customer with real history hits it.

Issue 1: the N+1 query

findByUserId fetches the orders. Then order.getItems() inside the loop lazily initializes the items collection, one order at a time. For N orders, Hibernate issues N+1 queries.

At low traffic this is invisible. At 2,000 req/min it multiplies your query volume by roughly the average number of orders per user.

Issue 2: blocking I/O inside the loop

This was the real killer. paymentClient.getStatus(...) is a synchronous REST call to an external Payment Service, averaging 350ms round trip.

With a typical 15 orders per user:

15 × 350ms = 5,250ms

Five seconds of network wait, in a loop, per request.

Now combine the two. That entire loop was running inside an open transaction, which means each request held a HikariCP connection for the full five seconds while doing nothing but waiting on a socket.

With a pool of 10, the arithmetic is brutal. Ten concurrent requests consume the entire pool. Every request after that queues on connection acquisition and eventually times out.

This is why the CPU stayed flat: the service was not overloaded, it was blocked.

Little's Law makes it concrete:

concurrency = arrival rate × latency

When latency jumps from 180ms to 5s, in-flight requests grow by nearly 30×. No pool sized for the healthy case survives that.

Issue 3: no transactional boundaries, no centralized error handling

Because the lazy collections were sometimes touched outside an active transaction, some responses came back with uninitialized item lists. That's the 3% of orders missing line items.

And with no @ControllerAdvice, each endpoint handled its own failures. Some leaked stack traces, some swallowed the exception and returned an empty 200. Clients had no consistent way to tell success from failure.

The fix

Three changes. None of them clever.

1. Fetch the relation explicitly

Replace the derived query with a JPQL query using LEFT JOIN FETCH, so orders and their items come back in one round trip.

@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {

    @Query("SELECT DISTINCT o FROM Order o LEFT JOIN FETCH o.items WHERE o.userId = :userId")
    List<Order> findByUserIdWithItems(@Param("userId") Long userId);
}

An @EntityGraph works equally well here if you prefer to keep the query derived.

2. Batch the external call, get it out of the loop

The Payment Service already had the capability to accept multiple IDs. We just weren't using it. One call replaces fifteen.

@RestController
@RequestMapping("/orders")
public class OrderController {

    private final OrderRepository orderRepository;
    private final PaymentClient paymentClient;

    @GetMapping("/{userId}")
    @Transactional(readOnly = true)
    public List<OrderDTO> getOrdersByUser(@PathVariable Long userId) {
        List<Order> orders = orderRepository.findByUserIdWithItems(userId);
        if (orders.isEmpty()) return Collections.emptyList();

        List<Long> orderIds = orders.stream().map(Order::getId).toList();
        Map<Long, String> paymentStatuses = paymentClient.getStatusesInBatch(orderIds);

        return orders.stream().map(order -> {
            OrderDTO dto = new OrderDTO();
            dto.setId(order.getId());
            dto.setStatus(order.getStatus());
            dto.setItems(order.getItems());
            dto.setPaymentStatus(paymentStatuses.getOrDefault(order.getId(), "UNKNOWN"));
            return dto;
        }).toList();
    }
}

Two things worth calling out.

getOrDefault(..., "UNKNOWN") means a partial failure in the payment lookup degrades one field instead of failing the whole response. And @Transactional(readOnly = true) gives us a defined boundary, so lazy access happens inside a live session rather than by luck.

If you can't batch on the downstream side, the fallback is parallel calls on a bounded executor. The rule you cannot break is the one about holding a database connection while you wait on the network.

3. Centralize exception handling

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(Exception.class)
    public ResponseEntity<Map<String, String>> handleAllExceptions(Exception ex) {
        log.error("Unhandled exception", ex);
        return ResponseEntity
            .status(HttpStatus.INTERNAL_SERVER_ERROR)
            .body(Map.of("error", "INTERNAL_SERVER_ERROR",
                         "message", "An unexpected error occurred."));
    }
}

Log the full detail on our side, return a stable shape to the client. No more stack traces on the wire, no more silent empty 200s.

Making it hold under burst: Redis

The code fix solved the incident. It didn't answer the next question, which was what happens when traffic goes past 2,000 req/min.

Order history is read-heavy and tolerant of being slightly stale, which makes it an easy caching target. We put @Cacheable on the read path with a 60-second TTL.

Sixty seconds was chosen deliberately. Long enough to absorb the repeated reads that dominate this endpoint, short enough that a status change surfaces well within what users notice.

Results

Metric	Before	After
p95 latency	4,200ms	< 5ms on cache hit
HikariCP pool usage	Saturated at 100%	Under 15% at peak
DB query pressure	Baseline	Down ~85%
Responses with missing items	~3%	0
Error responses	Inconsistent 500s / empty 200s	Consistent structured errors

What I'd tell any Spring developer after this

Never put network or database I/O inside a loop. Batch it, or make it non-blocking. This one rule would have prevented the entire incident.

A blocked thread holding a connection is worse than a slow one. Long I/O inside a transaction is how you exhaust a pool with modest traffic and idle CPUs. Do your external calls outside the transactional boundary.

Fetch explicitly when you're mapping to DTOs. JOIN FETCH or an entity graph. Never let lazy loading fire inside a mapping loop.

Low CPU with high latency is a diagnosis, not a mystery. It means blocking I/O. Go look at your pools and thread dumps, not your algorithms.

Centralize your error handling on day one. @ControllerAdvice costs ten minutes and saves you from leaking internals during the exact incident where you least want to be leaking internals.

Test with realistic data volumes. Every one of these bugs is invisible with three seeded rows and obvious with fifteen.

Have you hit connection pool starvation or thread exhaustion in production? I'm curious which anti-pattern caused it, because in my experience it's almost always this same shape wearing a different hat.

20 Agentic AI Terms Every Developer Should Know

Mohamed El Laithy — Sun, 06 Sep 2026 06:31:14 +0000

20 Agentic AI Terms Every Developer Should Know

TL;DR: Agent frameworks come with a vocabulary problem, not a complexity problem. Here are 20 terms, explained in plain language, each with a code-flavored example. Bookmark it — you'll be back.

The list, if you just want the names

AI Agent
Agentic Workflow
Agent Loop
Tool Calling
Agent Harness
Context Engineering
Memory
MCP
Planning
Reasoning
Multi-Agent Systems
Orchestration
Handoff
A2A
Guardrails
Human-in-the-Loop (HITL)
Evals
Computer Use
Agentic RAG
Agent Washing

Now the actual explanations.

1. AI Agent

An LLM that's allowed to take actions and decide what to do next, instead of replying once and stopping.

User: "Check why signups dropped yesterday."

Agent -> queries analytics DB
Agent -> checks yesterday's deploy log
Agent -> explains the drop, with evidence

A single reply, however smart, is not an agent. The willingness to go find out is the whole point.

2. Agentic Workflow

A workflow runs fixed steps in a fixed order, even if an LLM handles one of them. An agent decides its own next step as it goes.

# workflow: same order, every time
def handle_ticket(t):
    summarize(t)
    categorize(t)
    assign(t)

# agent: decides at runtime
# - categorize? ask a question? escalate first?

Same building blocks. Very different amount of control you're handing over.

3. Agent Loop

The cycle underneath every agent:

Decide -> Act -> Observe -> Decide -> ...

Decide: call checkInventory(). Act: makes the call. Observe: out of stock. Decide again: call notifySupplier() instead. Repeats until the goal is met, or the agent gives up.

4. Tool Calling

The model requests a function call. Your application executes it and returns the result. The model proposes, the application disposes.

Agent -> requests getFailedPayments()
App   -> executes it, returns rows
Agent -> reads the result, explains it

5. Agent Harness

The LLM is the brain. The harness is everything else that makes it work: tools, state, context, permissions, execution, error handling.

API call times out -> harness catches it, decides to retry, feeds the result back. The model never sees a raw exception. No harness, no agent — just a chatbot with opinions.

6. Context Engineering

Deciding what the model sees at each step, not writing one perfect prompt.

step_1..29: full history? // no
context = summarize(steps_1_28)
        + relevant_chunk(query)
        + step_29

7. Memory

Short-term: within one chat, it remembers you already tried restarting the app. Long-term: across sessions, it recalls you always ask in a specific language.

8. MCP

A standardized way for an AI app to plug into external tools and data.

Agent <-> MCP <-> Tools / Data

Instead of hand-coding a Postgres client and a Jira client separately, your agent talks to both through MCP servers, the same way.

9. Planning

Breaking a goal into steps before, or while, acting.

"ship this hotfix" ->
  run tests -> build -> deploy staging -> notify team

10. Reasoning

Working through why before acting. Three near-identical tools exist (refundPayment, voidPayment, reversePayment) — reasoning is what picks the right one before any call happens.

11. Multi-Agent Systems

Split the work across specialized agents instead of one generalist trying to do it all.

Coder agent    -> writes the diff
Reviewer agent -> checks the diff
Test agent     -> runs the suite, reports back

12. Orchestration

The layer deciding which agent runs when, and what data passes between them. It doesn't solve the task — it routes it.

ticket = classify(incoming)
if ticket.type == "billing":
    route(billing_agent, ticket)
else:
    route(technical_agent, ticket)

13. Handoff

One agent passing control and context to another, mid-task, so the user never repeats themselves.

14. A2A

Agent2Agent — a protocol for agents to talk to other agents, even ones built by a different team.

MCP -> Agent <-> Tools
A2A -> Agent <-> Agent

Don't mix these up. It's the single most common confusion in this list.

15. Guardrails

Automated rules that limit what an agent can do. Checked before execution, every time, no human required.

agent proposes: DROP TABLE users;
guardrail: only SELECT allowed -> blocked

16. Human-in-the-Loop (HITL)

A human has to approve an action before it happens. Not the same as a guardrail:

Guardrails = automated, no person involved
HITL = a person approves or blocks the action

agent.draft(refund, amount=2000)
status: PENDING_APPROVAL
-> waits for support_lead.approve()

17. Evals

Not just "was the final answer right." Also: tool selection, execution steps, task completion, reliability across runs.

eval.check(
  called_in_order = ["getOrderStatus", "issueRefund"],
  consistent_over = 50
)

18. Computer Use

The agent operates a UI directly — clicking, typing, reading screenshots — for the systems that never got an API.

screenshot = capture_screen()
button = locate(screenshot, "Approve")
click(button)

19. Agentic RAG

Traditional RAG: Retrieve -> Generate. Agentic RAG turns that into a loop:

Decide what to retrieve -> Retrieve -> Evaluate -> Retrieve again -> Generate

results = search(query)
if not good_enough(results):
    query = rewrite(query)
    results = search(query)
answer = generate(results)

20. Agent Washing

Calling something an "AI agent" when it's really just:

Prompt -> LLM -> Response

No loop. No tools. No autonomy. If there's no loop, no tools, and no autonomy — it's not an agent. It's a well-dressed prompt template.

That's 20. Which one did you have wrong until embarrassingly recently? Mine was Agentic RAG — I called it "RAG with extra steps" for way too long, which, in fairness, is also correct.

If you want more practical Java, Spring Boot, backend engineering, and AI content, I post regularly — and I've got deeper notes and templates at mellaithy.gumroad.com.

100 Spring AI Project Ideas You Can Build Without Touching Python

Mohamed El Laithy — Thu, 03 Sep 2026 09:00:26 +0000

Most Java developers think building AI features means learning Python first.

It doesn't.

Spring AI gives you ChatClient, VectorStore, function calling, and structured output — inside the same Spring Boot app you already know how to build, test, and deploy. You don't need to bolt on a separate Python service just to add a chatbot, a RAG pipeline, or an agent to your product.

To make that concrete, I put together 100 project ideas you can build with Spring Boot and Spring AI. Not vague titles — each one comes with the actual stack you'd reach for.

Here are five, to give you a feel for the format:

Project	Stack
Support Bot with RAG	Spring AI + pgvector + `QuestionAnswerAdvisor`
Meeting Notes Summarizer	`BeanOutputConverter` → `ActionItem` records
Natural Language to SQL	JDBC `DatabaseMetaData` for schema context
Repo-Aware Coding Agent	Tree-sitter + `VectorStore` + function calling
Voice Support Agent	WebSocket audio + RAG + function calling

The three tiers

The full list is organized by difficulty, so you can pick something that matches where you are right now instead of jumping straight into agent orchestration:

1–40 · Beginner — Spring Boot + Spring AI fundamentals: your first ChatClient calls, prompt templates, basic conversational endpoints.
41–80 · Intermediate — RAG pipelines and integrations: vector stores, document ingestion, structured output, calling external APIs from a model.
81–100 · Advanced — Agents and orchestration: multi-step reasoning, tool-calling agents, and systems that coordinate several models or services.

Why I'm doing this project by project

I'm building these one at a time — real code, real architecture decisions, and the parts that break along the way (because something always does). Each finished project gets a full write-up: what I built, the tradeoffs I hit, and the code itself.

Want the full list of all 100 projects (with stacks) as a PDF? Download it here — save it for later.

If you want to follow along as the series grows, I'm publishing every project on my Substack the day it's done — subscribe here to get each one as it lands.

I also run a small community for Java developers building with Spring Boot and Spring AI, if you want to talk through ideas or share what you're building: Global Java Developers Community.

Which one should I build first? Drop a number (or a project idea of your own) in the comments — I'm picking the next build from replies.

[Boost]

Mohamed El Laithy — Thu, 03 Sep 2026 08:57:15 +0000

Docker for Java Developers: The Interview Guide I Wish I Had Earlier

Mohamed El Laithy — Sat, 29 Aug 2026 10:34:40 +0000

Docker is no longer just a DevOps skill.

If you're a Java or Spring Boot developer, you'll likely face Docker questions in technical interviews — from basic containers and images to Dockerfiles, networking, volumes, and running Java applications in containers.

The problem?

It's easy to memorize Docker commands.

It's much harder to explain why things work the way they do.

That's why I created Docker for Java Developers — Interview Guide.

The guide is designed as a practical interview-focused reference for Java developers who want to:

Understand Docker fundamentals
Prepare for common Docker interview questions
Connect Docker concepts to Java applications
Review important commands and concepts quickly
Build stronger answers instead of memorizing definitions

If you're preparing for a Java, Spring Boot, Backend, or DevOps interview, this is a useful reference to keep nearby.

📘 Get the PDF: Docker for Java Developers — Interview Guide

Save it for your next interview preparation session.

Follow for more free content:

Instagram: https://www.instagram.com/mellaithy.tech/

Substack: https://substack.com/@mellaithy

LinkedIn: https://www.linkedin.com/in/mohamed-el-laithy-0155b2173/

The Spring Data JPA Mistakes That Don't Show Up Until Production

Mohamed El Laithy — Sat, 15 Aug 2026 11:08:49 +0000

Part 2 of Spring Boot Complete Notes — Data & Reliability

JPA is the easiest part of Spring Boot to get working and one of the easiest to get wrong in a way that only shows up once real traffic hits it. None of these four things will fail your build. All four will page you at 2 a.m.

Returning an entity is how you get infinite recursion

A Department holds a list of Employees. Each Employee holds a reference back to its Department. Perfectly normal bidirectional mapping.

@Entity
class Department {
    @OneToMany(mappedBy = "department", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Employee> employees = new ArrayList<>();
}

@Entity
class Employee {
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "department_id")
    private Department department;
}

Return either one directly from a @RestController and Jackson serializes forever: Department → Employees → Department → Employees → ... until you get a StackOverflowError or an OOM, depending on how patient the JVM is.

The instinct is to slap @JsonIgnore on one side. The actual fix is that entities never cross the controller boundary — map to a DTO at the edge, every time. It also solves the two other things exposing entities breaks: a lazy association throwing LazyInitializationException when Jackson touches it outside a transaction, and your database schema becoming your public API contract whether you meant it to or not.

CascadeType.ALL is a loaded gun

@OneToMany(mappedBy = "department", cascade = CascadeType.ALL, orphanRemoval = true)
private List<Employee> employees;

CascadeType.ALL includes REMOVE. Delete a Department and every Employee in it goes with it — no warning, no confirmation, just gone. This is correct behavior for a true parent-owns-child relationship (an Order and its OrderLines, say). It is almost never correct across what's actually an aggregate boundary, where Department and Employee are two independent things that happen to reference each other.

Cascade from parent to child only, and only when the child genuinely has no independent lifecycle. When in doubt, list the cascade types explicitly (PERSIST, MERGE) instead of reaching for ALL.

save() is not always an INSERT

userRepository.save(user);

If user has an id that already exists in the database, Spring Data JPA treats this as a merge, not an insert. No duplicate-key exception, no error — it silently becomes an UPDATE. This surprises almost everyone the first time it happens, usually while debugging why a "new" record overwrote an old one. If you need insert-or-fail semantics, that's a different method entirely, not save().

The N+1 you won't notice in dev

List<Department> departments = departmentRepository.findAll();
for (Department d : departments) {
    d.getEmployees().size(); // one query per department
}

50 departments, 50 lazy-loaded employee lists touched in a loop, 51 SQL statements for what should have been one. In development, with ten rows of seed data, this is invisible. In production, with real volume, it's the single most common cause of a "why is this endpoint suddenly slow" incident.

Turn on spring.jpa.show-sql=true in dev and you'll spot it immediately — one list endpoint producing 51 statements for 50 rows is the signature. The fix is a fetch join or @EntityGraph so the related data comes back in one query instead of N extra ones:

@Query("select d from Department d join fetch d.employees where d.id = :id")
Optional<Department> withEmployees(@Param("id") Long id);

A better habit than remembering to check: assert the query count in a test. A tool like datasource-proxy fails the build when an endpoint's statement count regresses, which is far more reliable than remembering to look at the console.

These four are a small sample of what's in Part 2 — Data & Reliability, one part of a four-part series (Spring Boot Complete Notes) covering the core web layer, the data layer, security, and production performance — written from scratch and checked line by line against current Spring Boot (3.5.x) and Spring Security 6, with a page in every part correcting the specific mistakes that keep circulating in outdated cheat sheets.

📄 Read Part 2 in full: Spring Boot Complete Notes — Part 2 (PDF)

The rest of the series (Core & Web Layer, Security & Observability, Performance & Delivery) is here: mellaithy.gumroad.com

The Modern SaaS Stack: 6 Tools Every Founder Needs in 2026

Mohamed El Laithy — Sat, 13 Jun 2026 13:36:50 +0000

6 AI tools you need to build your saas.pdf
The way we build software has fundamentally changed.
Five years ago, launching a SaaS meant assembling a team of specialists: a product manager to write requirements, an architect to design systems, senior engineers to review code, and DevOps engineers to handle deployment. It was expensive, slow, and only accessible to well-funded startups.

In 2026, the equation is different.

The solo founder or small team with the right tools can now accomplish what used to require a team of ten. But here's the catch: it's not about having more tools—it's about having the right tools that work together seamlessly.

After watching dozens of SaaS founders launch this year, a clear pattern has emerged. The winners aren't the ones with the biggest budgets. They're using a specific stack that combines AI-powered development, intelligent automation, and product obsession.

Here are the six tools every founder should know about in 2026.

1. Claude: Your AI-Powered Development Partner

Claude has become the default AI for serious SaaS builders.

It's not just a code generator (though it's excellent at that). Claude has become the scaffolding for your entire development process.

What separates Claude from other AI tools:

PRD writing: You describe your feature, Claude structures it into a professional requirements document. This forces clarity before coding.
System planning: Before writing a line of code, use Claude to architect your database schema, API design, and service interactions.
Production-ready code: Unlike AI code that requires heavy refactoring, Claude generates code that passes team review on the first pass.
From SaaS to Enterprise: It scales with your product, handling everything from early MVP to enterprise-grade architecture.

Why it matters: Development used to be a sequential process (plan → build → refactor → deploy). Claude compresses these steps. You still need the discipline to think things through, but the execution happens faster and with fewer errors.

The founders I've spoken to who use Claude are shipping 3-4x faster than the previous generation. That's not a small edge—that's the difference between reaching product-market fit before your runway ends or burning out trying.

2. Antigravity: The IDE Reimagined for AI

Google's Antigravity IDE represents a fundamental shift in how developers work.

Traditional IDEs were designed for one person typing code. Antigravity was designed for multiple AI agents working simultaneously.

Key capabilities:

Multi-agent coding: Run Claude and Gemini at the same time, letting them work on different parts of your codebase
One interface for everything: Write code, test it, debug it—all without context switching
Built for the next generation: This is an IDE designed from the ground up for AI-assisted development
Productivity multiplier: Early users report that they've never been more productive

The real advantage: Instead of writing code and then asking an AI to test it, you have AI agents that can propose changes, test them, and suggest improvements in real-time.

This is the IDE for developers who want to offload the tedious parts and focus on architecture and problem-solving.

3. Conductor: Automating the Bottleneck

Every growing SaaS team hits the same wall: too many features, too many bugs, and too much context-switching.

That's where Conductor comes in. It's a Claude Agent designed specifically for feature management and bug fixing.

What it does:

Consolidates your feature backlog: One place for all your requests, prioritized automatically
Fixes bugs autonomously: Instead of manually assigning and tracking issues, Conductor identifies problems and fixes them
Eliminates back-and-forth: No more "can you review this PR?" followed by three rounds of comments. Conductor handles coordination
Scales with large projects: Perfect when you're juggling dozens of active features and need someone (or something) to keep everything organized

Why this is a game-changer: The biggest bottleneck in SaaS teams isn't actually development—it's coordination. Conductor removes that entirely.

Founders tell me they've reclaimed 10+ hours per week just from reducing meeting overhead and context-switching. That's a whole developer's worth of productivity.

4. Vercel: Ship Your Frontend Instantly

Vercel is the gold standard for frontend deployment.

If you're building a modern web application (and you should be), Vercel is table stakes.

Why Vercel wins:

Deploy in seconds: Push to Git, and your code is live globally
Global edge network: Your frontend is served from the closest server to your users
Preview every change: Before merging to main, see exactly how your changes look in production
Git-native workflow: No special deployment processes—your Git workflow is your deployment workflow

The hidden advantage: Speed changes behavior. When you can deploy in seconds instead of minutes, you start shipping more frequently. And when you ship more frequently, you get faster feedback. That compounds.

Vercel also handles all the infrastructure complexity (CDN, caching, edge functions) that would otherwise require a dedicated DevOps engineer.

5. PostHog: Product Intelligence from Day One

Here's what separates successful SaaS founders from the rest: they obsess over how users actually interact with their product.

PostHog is the tool that makes this obsession operational.

What PostHog provides:

Built-in analytics: Not an afterthought—analytics are baked in from the first version
User feedback: Collect feedback directly in your app without redirecting users elsewhere
Behavioral data: Watch how people use your product, not just what features they use
Iteration engine: Every decision about your product should be informed by how people actually use it

Why it matters for SaaS: The difference between a product that achieves product-market fit and one that doesn't is usually a founder who obsessed over user behavior and iterated ruthlessly.

PostHog makes that obsession sustainable. You're not relying on support tickets or anecdotal feedback—you have real data about how your product is being used.

The Complete Picture: How These Tools Work Together

The real magic happens when these tools work in concert:

Claude helps you design the feature and architecture
Antigravity is where you build it, with AI assistance
Conductor manages the workflow and ensures quality
Vercel deploys it to production instantly
PostHog measures how users interact with it
That feedback loops back to Claude for the next iteration

This is the 2026 development cycle: idea to production to learning in hours, not weeks.

What This Means for Founders

If you're building a SaaS in 2026, you don't need to hire slowly and methodically. You can:

Get to a working MVP in weeks instead of months
Launch with a team of 1-3 people instead of 5-10
Measure everything your users do from day one
Iterate based on real behavioral data, not assumptions
Move faster than any traditionally-structured competitor

The capital requirement for founding a SaaS has dropped dramatically. The skill requirement hasn't—you still need to be thoughtful about what you're building and obsessive about user feedback. But the execution is now accessible to anyone with the right tools.

The founders I respect most in 2026 aren't the ones with the best developers (though they're smart about hiring). They're the ones who understand this stack deeply and use it to punch above their weight.

Next Steps

If you're building a SaaS:

Start with Claude for architecture and planning
Graduate to Antigravity when you have significant code
Add Conductor when feature management starts to overwhelm you
Deploy with Vercel from day one
Integrate PostHog before your first customer so you have data from the beginning

The time investment to learn these tools is minimal. The payoff is enormous.

What tools are you using in your SaaS stack? I'd love to hear what's working (and what isn't) in your experience. Drop a line in the comments.

This essay is part of my series on modern software development. Subscribe to stay updated on the latest tools, patterns, and practices that are reshaping how we build.

Backend Architectures Explained (Monolith vs Microservices vs Serverless vs Event-Driven)

Mohamed El Laithy — Wed, 29 Apr 2026 07:54:35 +0000

Choosing the right architecture is one of the most critical decisions in system design.

Let’s break down the 4 most common backend architectures and when to use each.

Monolithic Architecture

A single unified codebase where all components are tightly coupled.

✅ Use when:
Building MVPs
Small teams
Simple applications
👍 Pros:
Easy to develop & deploy
Faster initial development
Simple debugging
👎 Cons:
Hard to scale specific components
Single point of failure
Tight coupling

Microservices Architecture

Application is split into independent services communicating via APIs.

✅ Use when:
Large applications
Multiple teams
Need independent scaling
👍 Pros:
Scalability per service
Fault isolation
Team autonomy
👎 Cons:
Operational complexity
Data consistency challenges
Harder testing

Serverless Architecture

Functions triggered by events, no server management required.

✅ Use when:
Event-driven workloads
Unpredictable traffic
Cost optimization needed
👍 Pros:
Auto scaling
Pay-per-use
No infrastructure management
👎 Cons:
Cold starts
Execution limits
Vendor lock-in

Event-Driven Architecture

Services communicate via events (e.g., Kafka).

✅ Use when:
Real-time systems
High decoupling needed
Data streaming systems
👍 Pros:
Loose coupling
High scalability
Real-time processing
👎 Cons:
Debugging complexity
Event ordering issues
Data consistency challenges
🧠 Final Thought

There’s no “best” architecture.

👉 Start with a monolith
👉 Move to microservices when needed
👉 Use serverless for specific workloads
👉 Add event-driven for scalability & decoupling

💬 What architecture are you currently using?

The $0 Microservices Architecture That Actually Works (2026)

Mohamed El Laithy — Wed, 22 Apr 2026 09:59:07 +0000

Most engineers still believe one thing:

“Microservices = expensive infrastructure.”

That’s no longer true.

In 2026, you can build a scalable, production-ready microservices system without spending a dollar.

🧠 The Idea Behind This Stack

The goal isn’t just to make things “cheap.”

It’s to:

Keep services independent
Use async communication where it matters
Avoid vendor lock-in
Stay production-realistic

This isn’t a toy setup. This is something you can actually build on.

🧱 The Stack Breakdown

1. Frontend Layer

Use:

Next.js
Vercel (free tier)

This layer handles user interaction and sends requests to your backend.

2. API Gateway / Service Mesh

Spring Cloud Gateway
Istio or Linkerd

This is the entry point to your system:

Routes requests
Handles load balancing
Manages traffic

3. Service Discovery & Config

Eureka
Spring Cloud Config

Instead of hardcoding service URLs, services discover each other dynamically.

4. Core Microservices

Typical setup:

User Service
Order Service
Analytics Service

Each service:

Is independent
Can be deployed separately
Owns its own logic

5. Messaging Layer

Kafka
RabbitMQ

Used for:

Event-driven architecture
Async communication
Decoupling services

6. Data Layer

You don’t need expensive databases:

SQLite → lightweight services
DuckDB → analytics workloads
Supabase → hosted Postgres (free tier)

7. Deployment Layer

All free options:

Docker
Cloud Run
Cloudflare Workers
ECS/Fargate (free tier)

⚠️ The Tradeoffs

Let’s be real:

Free tiers come with:

Resource limits
Cold starts
Scaling constraints

But for:

Learning
Side projects
MVPs

This is more than enough.

🚀 Why This Matters

Because it removes the biggest excuse:

“I can’t build real systems without money.”

Now you can.

📌 Final Thought

The engineers who win in 2026 are the ones who:

Understand systems deeply
Optimize for cost
Move fast

This stack gives you all three.

🚀 100+ Spring Boot Tools You Should Know in 2026 (Complete Ecosystem Guide)

Mohamed El Laithy — Thu, 09 Apr 2026 12:30:35 +0000

Most developers think they understand Spring Boot…

Until they try to build something that actually runs in production.

You start with a simple REST API…
Then suddenly you need:

Security
Messaging
Monitoring
Deployment pipelines
Scaling strategies

And everything gets complicated fast.

🧠 Why This Matters

Spring Boot alone is not enough.

If you want to become a Senior Backend Engineer, you need to understand the entire ecosystem around it.

That’s exactly why I created this 👇

👉 A simplified map of 100+ Spring Boot ecosystem tools

This helps you see:

What tools exist
Where they fit
What you actually need to learn

🧩 The Spring Boot Ecosystem (Simplified)

Let’s break it down into the most important areas:

🌐 1. Web & APIs

This is where most developers start.

Spring Web (REST APIs)
Spring WebFlux (Reactive systems)
GraphQL Java
OpenAPI / Swagger
WebSockets

👉 These tools define how your services communicate.

🔐 2. Security & Authentication

No real system works without security.

Spring Security
OAuth2
JWT
Keycloak
Vault

👉 This is how you protect users and data.

🗄️ 3. Data Access

Managing data safely is critical.

Spring Data JPA
Hibernate
Flyway
Liquibase
JDBC

👉 This ensures consistency and reliability.

📩 4. Messaging & Event-Driven Systems

This is where systems become scalable.

Apache Kafka
RabbitMQ
Apache Pulsar
ActiveMQ

👉 Async communication = better performance & scalability.

⚙️ 5. DevOps & Infrastructure

Your code must run somewhere.

Docker
Kubernetes
GitHub Actions
Jenkins
CircleCI

👉 This is how you deploy and scale.

☁️ 6. Cloud & Microservices

Modern systems are distributed.

Spring Cloud (AWS, GCP, Azure)
Netflix Eureka
API Gateway

👉 This is how services discover and talk to each other.

📊 7. Observability (Most Ignored Skill 🚨)

Prometheus
Grafana
ELK Stack
Micrometer
Spring Boot Actuator

👉 If you can’t monitor it… you can’t fix it.

🧪 8. Testing

JUnit 5
Mockito
Testcontainers
RestAssured
WireMock

👉 This is how you build confidence in your system.

🧰 9. Utilities & Productivity

Lombok
MapStruct
Jackson
Guava

👉 These tools save time and reduce boilerplate.

💡 What Most Developers Get Wrong

They focus only on:

👉 Controllers
👉 Services
👉 Repositories

But ignore:

❌ Monitoring
❌ Deployment
❌ Scaling
❌ Failure handling

That’s why many apps fail in production.

🔥 How to Actually Learn This

Don’t try to learn everything at once.

Instead:

Master Spring Boot basics
Add Security
Add Database + Migrations
Add Docker
Add Observability
Then move to Microservices

👉 Learn in layers, not chaos.

🚀 Want a Production-Ready Setup?

If you want to skip the trial-and-error…

I built a complete Spring Boot Microservices package that includes:

✅ Real-world architecture
✅ API Gateway + Service Discovery
✅ Security implementation
✅ Docker setup
✅ Monitoring (Prometheus + Grafana)
✅ Clean and scalable structure

👉 Get it here:
https://mohamedmind11.gumroad.com

📢 Final Thoughts

Spring Boot is just the beginning.

The real skill is understanding:

👉 How systems behave in production
👉 How to scale
👉 How to debug failures

That’s what separates:

🧑‍💻 Junior Developers
from
🧠 Senior Engineers

If this helped you, leave a ❤️ and follow me — I share content about System Design & Backend Engineering.

How does a data ecosystem support executive management and decision-makers?

Mohamed El Laithy — Thu, 22 Jan 2026 09:24:57 +0000

The real challenge today in data ecosystems is not the theoretical definition, but translating it into a logic that decision-makers understand and creating tangible value for the organization.

The model in the attached image provides a practical concept that shows a data ecosystem is not a single layer, but a multi-layered system. It starts with a comprehensive operating model that links data strategy to organizational strategy and ends with transforming data into a final product that drives operational and strategic decisions.

⭐️ A data ecosystem consists of multiple layers:

Data Operating Model
▪️ Represents the broader strategic framework for data management across the organization and connects data strategy with organizational strategy.
▪️ Links data with governance, responsibilities, and decision-making structure.
▪️ Ensures coordination between departments instead of isolated work in silos.
💡 Main goal: Make data part of daily institutional operations.

Data Governance

Data Governance is the decision-making and accountability layer.
It answers essential questions such as:

✅ Who owns the data?
✅ Who decides how it is used?
✅ Who is responsible for its quality?

It focuses on:
✅ Defining decision-making authority
✅ Establishing data ownership at the domain level
✅ Implementing policies, controls, and standards
✅ Building trust in numbers and reports

Data Management

Data Management is the execution layer that applies governance decisions practically.
It answers the question: “How do we manage data within systems and platforms?”

It includes:
✅ Data quality monitoring
✅ Reference and master data management
✅ Data lineage tracking
✅ Metadata management
✅ Access controls and permissions

Data Products

Data Products are the final outputs seen by users and decision-makers.
They include reports, dashboards, and analytical datasets.

Data becomes valuable when it is:
✅ Reliable
✅ Reusable
✅ Linked to clear decision-making and operational scenarios

⭐️ Why is this important for decision-makers?
Because it shifts the conversation from “How do we implement data governance?” to “How does data enable decisions and reduce risks?”

This directly impacts:
✅ Higher trust in reports
✅ Stronger regulatory compliance
✅ Better readiness for AI applications
✅ Unified performance indicators
✅ Shared decisions across departments

💡 Conclusion:
The clearer and more governed this sequence is, the better an organization can transform data from an operational burden into a strategic asset that supports business efficiency and directly reflects on performance and institutional trust.

📌 Follow me for more AI content Linkedin.