Spring AOP.

Spring AOP is a favorite interview topic because it tests whether you understand what happens around a method call, not just inside it.

Question: What is Spring AOP, and why is it used?

Answer: Spring AOP is a way to add behavior around Spring bean methods without mixing that code into the business logic. It is mainly used for cross-cutting concerns such as logging, transactions, security, metrics, and caching. Under the hood, Spring usually does this with a proxy, which is a wrapper object that intercepts method calls.

Interview-Ready Answer: I use Spring AOP when I want to keep business code clean and move repeated concerns like logging, timing, security checks, or transaction handling into one place. In Spring Boot, AOP is usually proxy-based, so Spring wraps the bean and intercepts method calls before they reach the real object. One important detail is that self-invocation inside the same class bypasses the proxy, so the advice will not run unless the call goes through the Spring proxy.

What Spring AOP really is

Spring AOP solves the cross-cutting concern problem. A cross-cutting concern is logic that belongs in many places, but does not belong to the business rule itself. Examples are audit logs, retries, performance timing, transactions, and authorization checks.

Three words matter in interviews:

• Aspect: a class that groups cross-cutting logic.
• Advice: the action you want to run, such as before or after a method.
• Pointcut: the rule that selects which methods should get that advice.

In Spring AOP, a join point is usually a method execution on a Spring bean. Weaving means attaching the advice to the target execution path. Spring does this at runtime with a proxy, which is why it is easy to use in Spring Boot.

How it works under the hood

1. Spring starts the application and scans for beans, aspects, and advice annotations such as @Aspect, @Around, @Before, and friends.
2. For each bean that matches a pointcut, Spring creates a proxy instead of handing out the raw target object.
3. Your code calls the proxy, not the target directly. The proxy becomes the front door for that bean.
4. The proxy checks which advice applies to the method call and runs it in order.
5. If the advice is @Around, it can run code before the call, decide whether to continue, call proceed(), and then run code after the call.
6. The actual target method executes only if the advice chain allows it.
7. Return values and exceptions flow back through the advice, so you can log success, transform results, or handle failures.

Memory model: think of Spring AOP as a bouncer at the club door. If the customer enters through the front door, the bouncer can check them, stamp them, or stop them. If someone sneaks through a side door inside the club, the bouncer never sees it. That is the self-invocation gotcha.

Advice types in plain words

• @Before: run just before the method.
• @AfterReturning: run only if the method succeeds.
• @AfterThrowing: run only if the method throws.
• @After: run after completion, success or failure.
• @Around: wrap the method and control whether it runs at all.

Proxy style: JDK proxy vs CGLIB

Spring Boot commonly uses proxy-based AOP out of the box once the AOP starter is present. The important thing to remember is not the exact proxy class, but the boundary: the call must cross the proxy for advice to run.

Spring AOP vs alternatives

Use Spring AOP when the concern belongs to the method, not the HTTP request. Use a filter when the concern belongs to the incoming request, and an interceptor when you need MVC-level request processing.

Performance and edge cases

• The overhead is usually a small extra proxy call, so the cost is O(1) per advised method execution.
• The real cost is usually tiny compared with a database call or remote API call, but very chatty hot paths can feel it.
• Private methods, constructors, and self-invocation are common trouble spots because the proxy cannot intercept them in the same way.
• Spring AOP only works on Spring-managed beans. A plain object created with new is invisible to the proxy system.
• If you need deeper bytecode-level power, such as advising field access or constructor calls, full AspectJ weaving is the stronger tool.

So the short mental model is: Spring AOP is easy, practical, and perfect for method-level cross-cutting logic, but it is still a proxy system, not magic everywhere.

Real-World Story: Imagine an ecommerce checkout service. The team adds an aspect to measure payment latency and write audit logs whenever a card is charged. For external calls, everything looks great: dashboards show timing, and logs show success or failure. Then a developer refactors the code so placeOrder() calls charge() inside the same service class.

The team assumes the @Around advice still runs, but the internal call never leaves the object, so the proxy is bypassed. Suddenly the payment metrics drop to near zero, audit logs stop showing the real charge call, and support gets reports of missing trace lines during failures. Users may not see the bug directly, but operators see confusing logs, broken dashboards, and inconsistent incident timelines.

What goes wrong in practice:

• Symptoms: missing AOP log lines, underreported latency, and advice that seems to work only sometimes.
• Logs: the controller request appears, but the inner service method has no aspect output.
• User impact: hard-to-debug payment failures, missed audit events, and poor incident response.

The fix is to make the call cross the proxy boundary, for example by moving the advised method to another bean or by calling through the current proxy when that is appropriate. This is why AOP knowledge matters in production: a small misunderstanding can hide critical monitoring and make outages much harder to diagnose.

Follow-up & Tricky Questions:

• What is the difference between @Before and @Around? @Before can only run code before the method, while @Around wraps the method and can choose whether the method runs at all. If you need timing, retries, or short-circuiting, @Around is usually the right fit.
• Why does self-invocation bypass Spring AOP? Because the call stays inside the same object, so it never goes through the proxy. Spring only intercepts calls that enter through the proxy boundary.
• When would Spring use JDK proxies versus CGLIB? If a bean has an interface, Spring can use a JDK dynamic proxy; otherwise it uses class-based proxying such as CGLIB. The important practical limit is that final methods and classes are not safely interceptable with class-based proxies.
• Is Spring AOP the same as AspectJ? No. Spring AOP is proxy-based and usually limited to method execution on Spring beans, while AspectJ weaving is lower-level and can advise more join points such as constructors or field access.
• Where is @Transactional implemented? It is built on Spring AOP-style proxying. That is why transaction boundaries can also be lost on self-invocation.
• Will an aspect run on a private method? Usually no, because private methods are not invoked through the proxy in the normal Spring AOP model. Design the advice around public service methods instead.
• If I call an advised method with new instead of Spring, will the aspect run? No. Spring only advises beans it manages, so a manually created object is outside the proxy system.
• Can an aspect change the return value? Yes, especially with @Around, which can inspect or replace the returned object before sending it back to the caller.

Tricky / gotcha questions:

• Does putting @Trace on a method make every call to that method advised? No. The call must go through the Spring proxy; internal calls from the same class still bypass it.
• Can AOP intercept constructors? Not in normal Spring proxy-based AOP. Constructors run when the object is being created, before the proxy is ready.
• If a bean has no interface, does Spring AOP stop working? No. Spring can still use class-based proxying, but final methods and final classes become a problem.

Common Mistakes:

• Mistake: Thinking AOP is only for logging. Correction: It is also widely used for transactions, security checks, metrics, retries, and caching.
• Mistake: Forgetting that self-invocation bypasses the proxy. Correction: Move the advised method to another bean or call through the proxy when appropriate.
• Mistake: Expecting private, final, or constructor logic to be advised. Correction: Design around public bean methods, or use full AspectJ weaving if you need deeper interception.
• Mistake: Using AOP for request-level concerns that belong in filters or interceptors. Correction: Match the tool to the layer: HTTP, MVC, or service method.

Memory Hook: Spring AOP is a bouncer at the bean’s front door: calls that walk through the proxy get checked, stamped, and wrapped; side-door self-calls slip past unnoticed.

Cheat Sheet:

• Spring AOP = cross-cutting logic around Spring bean methods.
• Core pieces: aspect, advice, pointcut, join point, proxy.
• @Around is the most flexible advice type.
• Proxy must be crossed for advice to run.
• Self-invocation, private methods, and final methods are common gotchas.
• Use AOP for method concerns; use filters/interceptors for request concerns.

Practice Tasks:

• Add a second aspect that logs only failed method calls with @AfterThrowing.
• Create a new service interface and see how the proxy style changes when the bean has an interface.
• Move the charge() method into a separate bean and verify that the self-invocation problem disappears.